im not sure, but i think eip actually starts out with windows code thats involved in getting the process started... then it jumps to the entry point. For instance... when you get the threads context after createprocess the eip value is pointing to getcurrentdirectory in kernel32.dll
Posted on 2003-02-17 15:39:18 by BubbaFate
The report/reports in msdn say that later versions of XP are using same rules in NT. I thought I heard that XP was built on NT technology. I was surprized when you said it worked on your system. I'm be getting into it soon but right now work got in the way. :)
Posted on 2003-02-17 17:43:41 by mrgone
XP is considered an upgrade to Windows 2000... so yes the api is very similiar... there are only a few things that are XP specific and they mostly deal with the GUI.
Posted on 2003-02-18 06:37:23 by BubbaFate
Hey Bubba!

Yeah I have access to the thread but not the right one. I have two operating systems, Win98 and Win2k prof. In Win98 right after first single step exception it loads registers with environment of child process for instance the EIP jumps to first address 401000h. But that never happens in Win2k. I tried loading the Eip with set context and came up with a strange value somewhere in between even though I can modify other registers.
Posted on 2003-02-20 20:07:44 by mrgone
well there is only one thread in your test exe... its not like you can have the wrong one
Posted on 2003-02-20 20:20:15 by BubbaFate
WinDBG does the same thing. I never see the small program run but I see alot happen with an NTDLL
Posted on 2003-02-21 23:52:12 by mrgone
I went ahead and displayed all regesters and found that Eip never got set for some reason. It appears to be the segment of an NTDLL. So right after the break point exception I jam loaded the Eip with startup address offset. It finally ran the program but when the debuggee exits it returns to the NTDLL so to stop that I inserted an instruction count register to limit the the single steps. Other wize I would also continue to single step through the DLL which is about 57,000 instuctions.....lol. I need to look more into to environment of the processes or maybe you could help me with this. How could I get the number of instructions in the debuggee so that I can reset the trap flag when the program exits? I can do a memory dump of the debuggee but of course that won't give me the number.
Posted on 2003-02-22 22:15:45 by mrgone
Instructions are just a different interpretation of data, therefore you have to be able to tell the difference between code and data. There is no set number of bytes per instruction so you would have to disassemble the data and count the instructions while your doing it... This approach is extremely complicated and I doubt its reasonable to attempt it, AFAIK there is no program that can do this.

A more resonable thing to do is to debug the process your interested in, and trace it... counting the instructions each time you get a trace breakpoint... I remember seeing a program that did this, but I dont remember where... Also the results of doing this would be misleading if the debuggee has code branches.
Posted on 2003-02-22 23:48:08 by BubbaFate