VCamD.ax!CFactoryTemplate::CreateInstance() + 0x3f bytes
> VCamD.ax!CClassFactory::CreateInstance() + 0x7f bytes
What's 0x7f and 0x3f ?
views:
73answers:
3
+3
A:
Those values are the offset of the instruction pointer from the start of the listed function.
It's a way of expressing which assembly instruction is currently being executed in the function. Similar to having the the current source code line highlighted in the editor. Except that the offset is at the assembly level not the source code level.
JaredPar
2010-09-08 17:08:49
Do you know why sroll bar doesn't work normally when in **Disassembly** view?
2010-09-08 17:19:33
+1
A:
You got .pdb files that were stripped. Their source code file and line number info was removed. Typical for example for .pdb files you can get from the Microsoft symbol server.
Which is okay, you can't get the source code anyway. Without the line number info, the debugger falls back to using the 'closest' symbol whose address it does have available, typically the function entry point, and adds the offset of the call instruction.
Sometimes you get bogus information if debug info is missing for long stretches of code. That 'closest' symbol is in no way related to the original code. Any time the offset gets to be larger than, oh, 0x2000 then you ought to downplay the relevance of the displayed symbol name. There are a couple of places in the Windows code where you actually see the name of a string variable. The stack trace you posted has high confidence, those offsets are small.
Hans Passant
2010-09-08 17:20:24
An identifier in a program. Like the name of a function. CFactoryTemplate is the class name, CreateInstance is the method name. They are symbols in the debugging info file.
Hans Passant
2010-09-08 17:47:03
I feel another question coming. Please start another thread and close this one by marking it answered. And of course, don't hesitate to mark helpful answers.
Hans Passant
2010-09-08 18:15:56
+1
A:
If it's at the top of the stack, then it's the offset of the instruction pointer relative to the given symbol. So if the top stack frame is VCamD.ax!CClassFactory::CreateInstance() + 0x7f bytes, and VCamD.ax!CClassFactory::CreateInstance() is at location 0x3000 in memory (fictional obviously), then EIP is currently 0x307f. This shows you how far into the function you are.
If it's further up the stack then it's the return offset from the start of the given symbol. So if VCamD.ax!CFactoryTemplate::CreateInstance() called VCamD.ax!CClassFactory::CreateInstance(), and VCamD.ax!CFactoryTemplate::CreateInstance() is at location 0x4000 , then when VCamD.ax!CClassFactory::CreateInstance() returns, EIP will be at 0x403f.
One important thing to notice though is that if you see something like somedll!SomeFunc() + 0x5f33 bytes, you can be pretty certain that this is NOT the correct symbol. Since functions are rarely 0x5f33 bytes long, you can see that EIP is simply in a place that the debugger doesn't have symbols for.
tenfour
2010-09-08 17:26:40
You imagined the `EIP` thing,right? I can nowhere in visual studio see info about `EIP`
2010-09-08 17:31:47
In your watch window, type `@eip`, and it will show you the `EIP` register. Also see, http://en.wikipedia.org/wiki/Instruction_pointer
tenfour
2010-09-08 17:53:06
Oh I see it now,interesting! But in the "Disassembly" view,is it possible to dump all the assembly code? I tried but can only grab a screen of lines .
2010-09-08 18:01:23
no, the disassembly is quite a bit more complicated than normal source code for many reasons... there is just no good way of knowing the boundaries of the disassembly, and sometimes there's not even a perfect way to deduce the disassembly. remember in memory it's just a bunch of bytes. It may be treated as data or as code. You can technically jump (set EIP explicitly) to the middle of a multi-byte instruction, screwing up the disassembly entirely. If you want to disassemble DLL files, use IDA. There is a freeware version @ http://www.hex-rays.com/idapro/idadownfreeware.htm
tenfour
2010-09-08 18:19:14