This assert means that there is a mismatch somewhere between PAL_TRY and PAL_ENDTRY macros: if something within the PAL_TRY in your sample code can do a 'return' or some other control flow change without executing the code at PAL_ENDTRY, you'll see the assert.
The best way to debug it is to put a breakpoint on your new PAL_TRY, and when it hits, set breakpoints on PAL_EndTryHelper and PAL_TryHelper, then see where the mismatch happens. Within the helpers, the seh_info->bottom_frame points to a linked-list of active "try" blocks on the stack and the assert indicates that the PAL_ENTRY is trying to leave, but isn't the bottom-most node in the list. Barry This posting is provided "AS IS" with no warranties, and confers no rights. -----Original Message----- From: Discussion of the Rotor Shared Source CLI implementation [mailto:[EMAIL PROTECTED] On Behalf Of Archana Sent: Wednesday, July 16, 2003 5:16 AM To: [EMAIL PROTECTED] Subject: [DOTNET-ROTOR] usage of PAL_TRY Hi, in the process of making changes to the garbage collector, i added a few PAL_TRY blocks in gcsmp.cpp. of the following form PAL_TRY { .. if(error) PAL_LEAVE_EX(labelxx); } PAL_EXCEPT_FILTER_EX(labelxx, HandleGCException, NULL) { .. } PAL_ENDTRY but when i debug a simple application, i get the following Assert at the first PAL_ENDTRY that i added.. {0804D000} ASSERT [EXCEPT ] at ../exception.c.442: Exception registration pointers don't match! and if i comment all these it throws up the same assert at another point, in appdomain.cpp (SystemDomain::CreatePreallocatedExceptions) at the COMPLUS_CATCH statement. can you please help. Thanks and regards, archana
