jmp $FCE2:

Here is the latest version of (contains minor changes)

Eventually I will have to look at EPROCESS again. Hopefully I'm able to post XP structs next week

To help speed things up for you I have also added to the attached file a rough draft (called rev 1.0 in the file) of the file, which contains the following structs:


(NOTE: These two include files were not ment to be used together in a source file as I have not taken the time to eliminate duplicate definitions).

Hope this helps
Posted on 2001-12-10 15:11:00 by madprgmr

for the last week I was very busy on my project and didn't have time to read win32asm forums. Alas ! I didn't make alot of progress. Your help & include files are greatly appreciated, mad.
Posted on 2001-12-16 01:23:49 by jmp $FCE2
Looking through XP's EPROCESS I'm not surprised my program wouldn't work :grin: You really saved me alot of time on this one. Marvellous stuff. Perhaps I shouldn't ask this, but where'd you get that information from ? No problem if it's none of my business. I'm just curious.
Posted on 2001-12-16 22:43:06 by jmp $FCE2
You really saved me alot of time on this one.Marvellous stuff

Glad to see that it is of use.

where'd you get that information from

I just used the standard methods and tools available to anyone interested in, or who's main job involves, systems level development. All the information that you seek is there to be had (for free)and Microsoft is more than willing to assist you, by providing the means. You just need to know how to utilize the available tools.

For example, to obtain systems level structure information (i.e. Eprocess) {how it is used is a subject for another day} within WindowsXP just do the following:

1) Download the latest version of the Windows Debugger
2) Download the Symbols for WinXP
3) Install both #1 and #2
4) Create a Crash Dump from a system running WinXP
5) Load the Crash Dump into the Windows Debugger
6) From the command window issue the command:

and the rest is up to you to format, verify sizes, and to create the proper assembly for each structure contained within.

I hope the above information helps in your future endeavors:alright:
Posted on 2001-12-17 12:57:59 by madprgmr
Heh, I've made a note of it, but I have only one machine and W2K on it. I don't exactly like dual-boot machines and I prefer W2K over XP.

Wonder why M$ has completely changed EPROCESS' layout. Well, we're NOT supposed to use it directly, sure, but they've (randomly ?) just changed positions of some structure members, introduced some new ones, thrown out others. Whatever, it's M$s' code, not mine :tongue:
Posted on 2001-12-17 15:44:04 by jmp $FCE2
If you wish to perform the same type of work on a Win2K system then I would recommend that you use the following command rather than the dt command:
!kdex2x86.strct <structure> <address>

For example, to dump just an eprocess you would use:

!kdex2x86.strct eprocess

Now if you wanted to display a block of memory as an eprocess then you would do this:

!kdex2x86.strct eprocess 0x80000000

Now concerning the need for two machines, here is what you can do to get around that:

1) Setup your machine to allow the generation of a full crash dump (information on how to do this is contained within the Windows Debugger help file)
2) Setup your machine to enable keyboard crash dumps (Again information on how to do this is contained within the Windows Debugger help file, just search for crash dump)
3) Create your crash dump file by BSOD'ing your system via the keyboard method explained above
4) Reboot your system
5) When the system comes back up, give it a few to rip out the crash information from the page file and place it into the Memory.dmp file.
6) Load up the memory.dmp file inside the Windows Debugger.

That's all there is to it; as you can see you will not need two machines (unless you do not feel safe BSOD'ing your main system).

The only problem with doing all of this is that it does not give you the benefit of a live walk-thru. So, what I do is to load up my crash dump into the windows debugger on one system and walk through the same code on another system using SoftIce (Don't forget to translate those symbols from Microsoft format to Numega format).

With all of these tools and methods in place, you are set; no more working in the dark when it comes to Windows System Internals.:alright:

Just think, skills that have taken me years to learn and perfect have been passed on in a matter of a few posts to this message thread. Just keep in mind, knowing what tools to use and how best to use them is a major portion of the battle.

Enjoy and let me know how your include files and the end result of your work turns out.
Posted on 2001-12-17 16:44:22 by madprgmr