views:

324

answers:

2

Hi all,

I am using MS Visual Studio 2005 (C++)..

Could anyone tell me what could cause a runtime exception like so..?

Unhandled exception at 0x07ed0027 (xxx.dll) in yyy.exe: 0x80000001: Not implemented.

xxx.dll is a dll i am working on and yyy.exe is an exe that is calling that dll.. When the undhandled exception comes up while debugging, it takes me to a function but I can't see anything wrong with the function (it doesn't raise the exception everytime this function is called). Anyway, I checked all the values in the function and they seem ok.. If I click continue instead of break, or press F5 after the break, then it goes on like nothing happened.. Please let me know if I haven't supplied enough information..

Thanks.

+1  A: 

I think exception filters might help you to get more details.

USe SetUnhandledExceptionFilter to set the un-handled exception filter and check where exactly exception is getting thrown.

aJ
Thanks I'll check this out..
krebstar
I tried to use it but I can't seem to get it to work.. I tried SetUnhandledExceptionFilter(NULL); but nothing's changed.. How do I make a function filter?
krebstar
You need to write a function and pass the function name ( function pointer ) to SetUnhandledExceptionFilter. The control will come to this function when exception occurs.
aJ
Hmm okay.. Will see if I can make some use of this info.. Thanks..
krebstar
+3  A: 

Like the more familiar 0xC0000005, 0x80000001 is the code of an exception that's being raised. You can look them up in winnt.h. In this case, I've found #define STATUS_GUARD_PAGE_VIOLATION ((DWORD )0x80000001L)

Guard pages are used for stack growth. The first page after the top of the stack is marked as a guard page. When you write to that - typically by pushing more data on the stack - a guard page exception is taken. The OS allocates an extra page or RAM (or perhaps 2 - details left to the OS) and moves the guard page up.

MSalters
Thanks, this is good to know.. If I understand correctly, something is pushing more data than can fit on the stack..? In my specific case, it seems unlikely, it is breaking on a line where I have void pointer casted to a structure pointer, and then checked like so:...if (pToStruct->aStructMember==NULL)...I checked the values here and they were okay...Thanks..
krebstar
That's one alternative. Another option is that you touch the guard page because of a bug. For instance, if `pToStruct` points to the stack, but the object on the stack doesn't actually have that type, then offsetof(aStructMember) could be too big and cause a read of an uninitialed guard page. Note that you don't usually see a guard page exception, but normally you start wtih a write not a read.
MSalters
So you are saying that maybe the object that void pointer that I typecasted to a structure pointer could be pointing to an object that is not of the said structure and is misreading it? Hmm.... Need to do more investigation..
krebstar
I didn't know yet you were casting a `void*`. But yes, misuse of casts is a common bug, and could definitely cause this.
MSalters