Hi all,

I looked around the Net but didn't find any comprehensive doc cover this topic.

I wrote my own SEH handler, and it works perfectly in Windows ME .. but it silently quits in Windows 2000.

Basically what my code does is:

1) Install my SEH handler:

the structure:
.PrevLink: DS.P32 1
.CurrentHandler: DC.P32 SEH.CALLBACK

the code that installs the handler:
MOV EAX,U32 [FS:0]


the handler:
messagebox something
free everything I allocated in my program

As I said, it works perfectly in Windows ME (only one weird thing: it always reports exception code C0000027, regardless if it was e.g. an access violation or a division by zero), but in Windows 2000 it quits my app (the handler gets installed, but as it seems it gets never called.. Windows 2000 silently quits my app and that's all).

Does anybody have some hints to offer, please?


PS: In other, old posts:

Noodle wrote (in the post "Main > Problems with my own SEH (with MASM)"):
FS is assumed by masm to be something other than data i think, its not afaik a specific selector and can like GS or ES be used to access any special case segment. In windows some OS specific things are kept in the FS segment like the SEH structure, the process and thread handles/ids and tls slots and many other things.
Does anybody have a doc describing in detail all these structures?


f0dder wrote (in the post "Main > SIDT / IDT problem in Win XP"):
Use VirtualAllocEx and position-independant code, decrypt,
decompress, and use that for some critical code code fragments.

These tricks are clean, in the sense that they will run on any win32
(if implemented correctly), don't target any specific tool, and do not
require administrator privileges.
AFAIK only NT supports VirtualAllocEx.. i.e. 9x doesn't. Am I right? Or maybe Windows 98 and ME support it, and only 95 didn't?


By the way, f0dder, you give a very good advice: install your own INT3 handler than does things vital to the application, so to bother the cracker. I assume you mean that our INT3 handler will be installed as a SEH handler, and not directly in the IDT (which sure wouldn't be easy on NT anyway). But don't (I ask, I don't know it) good ring0 debuggers like SoftIce install themselves directly in the IDT, maybe as a hook, thus allowing then the normal call to the SEH handler? If not, do you think that anyway SoftIce & Co. could be modified to feature this? I just wonder if I really should make a INT3 handler/server for my app, and how much will it offer to my protection.
Posted on 2002-03-31 08:15:49 by Maverick
I don't know much about SEH, but here's an article at MSDN written by Matt Pietrek:


VirtualAllocEx is an NT-only function. The platform SDK says:

Windows NT/2000/XP: Included in Windows NT 4.0 and later.
Windows 95/98/Me: Unsupported.

Posted on 2002-03-31 08:58:04 by Thomas
Thank you very much Thomas, I will look at it.
Posted on 2002-03-31 15:05:02 by Maverick
Both this problem, and the one in this post were due to the fact that from time to time Windows checks that ESP points to "valid" stack area. Also, against any sense IMHO (and documentation), Windows 2000 *pretends* that the EXCEPTION_REGISTRATION record be in the stack.

I solved both problems by simply forcing effectively no "stack checking".. allowing myself to set ESP wherever I wish (e.g. in the heap, this allows me to switch stack in the rare special cases that I need it (not so rarely, actually)):

MOV U32 ,0x00000000

That's all..
Posted on 2002-04-01 02:42:32 by Maverick