0

Does calling the ntdll!_SEH_epilog function, synonym of emmiting a system SEH exception ?

I have dozens of dump files which display the same stacktrace. It's in a mixed C++/C# environment.

CLR's legacyCorruptedStateExceptionsPolicy enabled="true" has been set for the product. And we also have our own SEH Handler, which is namely responsible for the dump file generation.

However, analyzing the dump file, I wonder if I'm not analyzing the problem too late, too late in the stack.

Because, if I look at the very very beginning of the really long managed/native stack, there's a ntdll!_SEH_epilog, before the problem that I have been focused on for now. (What I have analyzed for now is pointed by the dump file as a NullReferenceException. But at this point it is indeed really hard to have a null object, unless new has return null...)

In a nutshell windbg !dumpstack look like this, and I suspect the line 0905fd18 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog at the bottom to be indeed the original problem.

0:023> !dumpstack
0905a008 7c8094e5 kernel32!CreateFileMappingW+0x10b , calling ntdll!NtCreateSection
0905a7ec 59a8ba78 dbghelp!MiniDumpWriteDump+0xc8 , calling dbghelp!MiniDumpProvideDump
...
OurNativeSEHManagement::CreateDumpFile+0x155                                                                                                      <== write the dump file
...
0905ef6c 7920cb4e clr!CLRVectoredExceptionHandlerPhase2+0xff , calling clr!_EH_epilog3
...
0905efa4 0040e9de OurNativeSEHManangement::ProcessException <== this is our own SEH management
0905efdc 004127a5 OurNativeSEHManangement::HandleException  <== this is our own SEH management
0905eff8 7c9444a8 ntdll!RtlCallVectoredExceptionHandlers+0x48 
0905f018 7c933f56 ntdll!RtlDispatchException+0x19 , calling ntdll!RtlCallVectoredExceptionHandlers
...
0905f084 7915c620 clr!SigPointer::SizeOf+0x17c , calling clr!_EH_epilog3
0905f090 7c90e48a ntdll!KiUserExceptionDispatcher+0xe , calling ntdll!RtlDispatchException

*** a null reference exception is emitted in the line below ***
0905f398 088d4da3 (MethodDesc 0871df48 +0x13 One.Of.Our.Business.Class.ProxyStateHandler(System.Object, System.EventArgs)) ====> Exception Code c0000005 cxr@905f0c4 exr@905f0a8  <== this one is due to a NullReferenceException
...
0905f34c 7c910323 ntdll!RtlpImageNtHeader+0x56 , calling ntdll!_SEH_epilog
0905fc40 7c91abe7 ntdll!LdrpInitializeThread+0x13b , calling ntdll!_SEH_epilog
...
0905fca8 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog

*** is the following line the original problem indeed ? ***
0905fd18 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog 
0905fd1c 7c90d06a ntdll!ZwContinue+0xc 
0905fd20 7c90e45f ntdll!KiUserApcDispatcher+0xf , calling ntdll!ZwContinue
0905ffa0 791f59f6 clr!Thread::intermediateThreadProc+0x39 , calling clr!_alloca_probe_16
0905ffb4 7c80b729 kernel32!BaseThreadStart+0x37

Below, I include a more complete, yet still extremely simplified stacktrace ( I removed lots of lines, but it keeps the spirit of the original 900 lines stacktrace)... Overall it looks like a fireworks of SEH for my eyes, if ever calling ntdll!_SEH_epilog is really synonym of emitting a system SEH exception.

Should I consider the first occurrence of ntdll!_SEH_epilog as the real problem, or first consequence of the real problem ?

0:023> !dumpstack
OS Thread Id: 0x5d0 (23)
Current frame: ntdll!KiFastSystemCallRet
ChildEBP RetAddr  Caller,Callee
0905a004 7c90d18a ntdll!NtCreateSection+0xc 
0905a008 7c8094e5 kernel32!CreateFileMappingW+0x10b , calling ntdll!NtCreateSection
0905a020 7c80b9d7 kernel32!CreateFileMappingW+0x14a , calling kernel32!SetLastError
...
0905a1fc 59a8c4a0 dbghelp!GenAllocateModuleObject+0x2ce , calling dbghelp!_SEH_epilog
...
0905a288 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905a454 7c9101db ntdll!RtlAllocateHeap+0xeac , calling ntdll!_SEH_epilog
...
0905a620 59a8ac32 dbghelp!WriteFullMemory+0x1e1 
0905a694 59a8b7d8 dbghelp!WriteDumpData+0xfd , calling dbghelp!WriteFullMemory
0905a6b0 59a8b97b dbghelp!MiniDumpProvideDump+0x171 , calling dbghelp!WriteDumpData
0905a7ec 59a8ba78 dbghelp!MiniDumpWriteDump+0xc8 , calling dbghelp!MiniDumpProvideDump
...
OurNativeSEHManagement::CreateDumpFile+0x155  <== write the dump file
... at least one hundred of ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog ...
0905c5f0 7c910041 ntdll!RtlFreeHeap+0x1e9 , calling ntdll!RtlpFreeToHeapLookaside
0905c5f8 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c610 7c91080b ntdll!RtlFreeHeap+0x2e9 , calling ntdll!RtlpCoalesceFreeBlocks
0905c618 7c910940 ntdll!RtlFreeHeap+0x4fc , calling ntdll!RtlLeaveCriticalSection
0905c620 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c630 7c9100b8 ntdll!RtlpFreeToHeapLookaside+0x22 , calling ntdll!RtlpInterlockedPushEntrySList
0905c63c 7c910041 ntdll!RtlFreeHeap+0x1e9 , calling ntdll!RtlpFreeToHeapLookaside
0905c644 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c660 79175deb clr!RtlFreeHeap+0x2f , calling ntdll!RtlFreeHeap
0905c674 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905c6f8 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42 , calling ntdll!_SEH_epilog
0905c724 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42 , calling ntdll!_SEH_epilog
0905c728 7c91019b ntdll!RtlAllocateHeap+0x1c2 , calling ntdll!RtlpAllocateFromHeapLookaside
0905c72c 7c9101db ntdll!RtlAllocateHeap+0xeac , calling ntdll!_SEH_epilog
0905c73c 79151995 clr!SArray<DataImage::RvaInfoStructure,1>::~SArray<DataImage::RvaInfoStructure,1>+0x27 , calling clr!_EH_epilog3
0905c760 79151995 clr!SArray<DataImage::RvaInfoStructure,1>::~SArray<DataImage::RvaInfoStructure,1>+0x27 , calling clr!_EH_epilog3
...
0905c790 79170b8a clr!AssemblySpec::LoadDomainAssembly+0x389 , calling clr!_EH_epilog3_GS
...
0905c860 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c880 7c9100b8 ntdll!RtlpFreeToHeapLookaside+0x22 , calling ntdll!RtlpInterlockedPushEntrySList
0905c88c 7c910041 ntdll!RtlFreeHeap+0x1e9 , calling ntdll!RtlpFreeToHeapLookaside
0905c894 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c8a0 7c9100b8 ntdll!RtlpFreeToHeapLookaside+0x22 , calling ntdll!RtlpInterlockedPushEntrySList
0905c8ac 7c910041 ntdll!RtlFreeHeap+0x1e9 , calling ntdll!RtlpFreeToHeapLookaside
0905c8b4 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905c974 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905c9a8 7919c07e clr!operator delete+0x41 , calling clr!_EH_epilog3
...
0905ca08 79157057 clr!ClassLoader::LoadTypeDefThrowing+0x2f3 , calling clr!_EH_epilog3_GS
...
0905ca6c 791a7c6b clr!ClassLoader::FindClassModuleThrowing+0x190 , calling clr!_EH_epilog3_GS
0905cac4 79157057 clr!ClassLoader::LoadTypeDefThrowing+0x2f3 , calling clr!_EH_epilog3_GS
...
0905cb24 791d5ce7 clr!TypeName::GetTypeHaveAssemblyHelper+0x666 , calling clr!_EH_epilog3_catch_GS
...
0905cc30 7914f062 clr!MethodDesc::FindOrCreateAssociatedMethodDesc+0x5f , calling clr!_EH_epilog3_GS
...
0905cd98 791d5a44 clr!TypeName::Factory<InlineSString<128> >::Factory<InlineSString<128> >+0x44 , calling clr!_EH_epilog3
...
0905cdb0 791d5a44 clr!TypeName::Factory<InlineSString<128> >::Factory<InlineSString<128> >+0x44 , calling clr!_EH_epilog3
0905cde0 7916f3e8 clr!SystemDomain::GetCallersModule+0x45 , calling clr!Thread::StackWalkFrames
0905cdf0 7916f418 clr!SystemDomain::GetCallersModule+0x72 , calling clr!_EH_epilog3
0905ce34 791d5ce7 clr!TypeName::GetTypeHaveAssemblyHelper+0x666 , calling clr!_EH_epilog3_catch_GS
...
0905ce50 791d53d4 clr!TypeName::GetTypeWorker+0x1c1 , calling clr!_EH_epilog3_catch_GS
...
0905cf9c 79151995 clr!SArray<DataImage::RvaInfoStructure,1>::~SArray<DataImage::RvaInfoStructure,1>+0x27 , calling clr!_EH_epilog3
...
0905cfc4 791d59fd clr!TypeName::TypeName+0xf6 , calling clr!_EH_epilog3_GS
...
0905d08c 7914f062 clr!MethodDesc::FindOrCreateAssociatedMethodDesc+0x5f , calling clr!_EH_epilog3_GS
...
0905d0b4 79158a2d clr!MemberLoader::GetDescFromMemberDefOrRefThrowing+0x6c , calling clr!_EH_epilog3
...
0905d1a4 791505eb clr!ClassLoader::EnsureLoaded+0xd3 , calling clr!_EH_epilog3_GS
...
0905d1dc 79141ad1 clr!_EH_epilog3_GS+0xa , calling clr!__security_check_cookie
0905d1e0 7914f320 clr!SigPointer::GetTypeHandleThrowing+0x1038 , calling clr!_EH_epilog3_GS
...
0905d2e4 7914f320 clr!SigPointer::GetTypeHandleThrowing+0x1038 , calling clr!_EH_epilog3_GS
...
0905d330 791a9863 clr!Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>::~Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>+0x2b , calling clr!_EH_epilog3
0905d354 79141b19 clr!_EH_epilog3_catch_GS+0xa , calling clr!__security_check_cookie
...
0905d3fc 791a9863 clr!Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>::~Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>+0x2b , calling clr!_EH_epilog3
0905d424 791acb3e clr!CEEInfo::getArgNext+0x133 , calling clr!_EH_epilog3
...
0905d4d0 791a9863 clr!Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>::~Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>+0x2b , calling clr!_EH_epilog3
0905d4f8 791ab805 clr!CEEInfo::getCallInfo+0x13f , calling clr!_EH_epilog3
...
0905d6c0 791aa9ad clr!getMethodInfoHelper+0x29a , calling clr!_EH_epilog3_GS
...
0905d724 791ac4d4 clr!canReplaceMethodOnStack+0x154 , calling clr!_EH_epilog3
...
0905d75c 791a9863 clr!Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>::~Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>+0x2b , calling clr!_EH_epilog3
...
0905d9e8 71a916a3 wshtcpip!WSHGetSocketInformation+0x23a , calling wshtcpip!_SEH_epilog
...
0905da3c 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905da88 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905dab4 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905dafc 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905db40 7c911429 ntdll!RtlDeleteCriticalSection+0x83 , calling ntdll!_SEH_epilog
...
0905db74 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905db78 71a54230 mswsock!SockDestroySocket+0x17d , calling ntdll!RtlFreeHeap
0905db9c 71a541be mswsock!WSPCloseSocket+0x314 , calling mswsock!SockDestroySocket
0905dba0 71a541cd mswsock!WSPCloseSocket+0x329 , calling mswsock!_SEH_epilog
...
0905dfe8 7914f320 clr!SigPointer::GetTypeHandleThrowing+0x1038 , calling clr!_EH_epilog3_GS
...
0905e25c 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905e31c 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905e650 7916c76d clr!COMDelegate::InternalEqualTypes+0x150 , calling clr!_EH_epilog3
0905e698 7916c76d clr!COMDelegate::InternalEqualTypes+0x150 , calling clr!_EH_epilog3
...
0905e834 79164a60 clr!CallDescrWorkerWithHandler+0x161 , calling clr!_SEH_epilog4_GS
...
0905e88c 79164a60 clr!CallDescrWorkerWithHandler+0x161 , calling clr!_SEH_epilog4_GS
...
0905ea08 791d787a clr!CallWithValueTypes_RetArgSlotWrapper+0xc2 , calling clr!_SEH_epilog4_GS
...
0905ebc4 791d787a clr!CallWithValueTypes_RetArgSlotWrapper+0xc2 , calling clr!_SEH_epilog4_GS
...
0905ee6c 7915c620 clr!SigPointer::SizeOf+0x17c , calling clr!_EH_epilog3
0905ee9c 79161987 clr!SimpleRWLock::EnterRead+0xb4 , calling clr!_EH_epilog3
...
0905eef4 7920ceae clr!DebuggerController::DispatchNativeException+0x168 , calling clr!_EH_epilog3
0905ef0c 7949b63f clr!IsIPInModule+0x89 , calling clr!_SEH_epilog4
...
0905ef34 7920ce86 clr!Debugger::FirstChanceNativeException+0x6a , calling clr!_EH_epilog3
...
0905ef6c 7920cb4e clr!CLRVectoredExceptionHandlerPhase2+0xff , calling clr!_EH_epilog3
...
0905efa4 0040e9de OurNativeSEHManangement::ProcessException  <== this is our own SEH management
0905efdc 004127a5 OurNativeSEHManangement::HandleException    <== this is our own SEH management
0905eff8 7c9444a8 ntdll!RtlCallVectoredExceptionHandlers+0x48 
0905f018 7c933f56 ntdll!RtlDispatchException+0x19 , calling ntdll!RtlCallVectoredExceptionHandlers
...
0905f084 7915c620 clr!SigPointer::SizeOf+0x17c , calling clr!_EH_epilog3
0905f090 7c90e48a ntdll!KiUserExceptionDispatcher+0xe , calling ntdll!RtlDispatchException
0905f398 088d4da3 (MethodDesc 0871df48 +0x13 One.Of.Our.Business.Class.ProxyStateHandler(System.Object, System.EventArgs)) ====> Exception Code c0000005 cxr@905f0c4 exr@905f0a8        <================= this one is due to a NullReferenceException
...
0905f34c 7c910323 ntdll!RtlpImageNtHeader+0x56 , calling ntdll!_SEH_epilog
0905f378 7c910323 ntdll!RtlpImageNtHeader+0x56 , calling ntdll!_SEH_epilog
...
0905f380 7c812d27 kernel32!GetProcessVersion+0x12c , calling kernel32!_SEH_epilog
... HERE SOMETHING IS TRIGGERED IN OUR BUSINESS CODE
0905f404 79161f8e clr!PreStubWorker+0x165 , calling clr!_EH_epilog3
...
0905f5d8 7c912d90 ntdll!LdrUnlockLoaderLock+0xb1 , calling ntdll!_SEH_epilog
...
0905f6d4 7c80e544 kernel32!GetModuleHandleForUnicodeString+0xa0 , calling kernel32!_SEH_epilog
0905f6f4 7c80e544 kernel32!GetModuleHandleForUnicodeString+0xa0 , calling kernel32!_SEH_epilog
...
0905f6fc 7c80e6cb kernel32!BasepGetModuleHandleExW+0x250 , calling kernel32!_SEH_epilog
0905f780 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42 , calling ntdll!_SEH_epilog
0905f7ac 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42 , calling ntdll!_SEH_epilog
...
0905f7b4 7c9101db ntdll!RtlAllocateHeap+0xeac , calling ntdll!_SEH_epilog
0905f834 7c912d90 ntdll!LdrUnlockLoaderLock+0xb1 , calling ntdll!_SEH_epilog
...
0905fac4 7c80e6cb kernel32!BasepGetModuleHandleExW+0x250 , calling kernel32!_SEH_epilog
...
0905fb10 603b4139 mscoreei!_initptd+0x9b , calling mscoreei!_SEH_epilog4
...
0905fb1c 603b42be mscoreei!_CRT_INIT+0x161 , calling mscoreei!_SEH_epilog4
0905fb78 7c80e6cb kernel32!BasepGetModuleHandleExW+0x250 , calling kernel32!_SEH_epilog
...
0905fb90 77a817ac crypt32!I_CryptTlsDllMain+0x195 , calling crypt32!_SEH_epilog
...
0905fc40 7c91abe7 ntdll!LdrpInitializeThread+0x13b , calling ntdll!_SEH_epilog
...

*** is this line the original problem indeed ? ***
0905fca8 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog
0905fd18 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog                                                         
0905fd1c 7c90d06a ntdll!ZwContinue+0xc 
0905fd20 7c90e45f ntdll!KiUserApcDispatcher+0xf , calling ntdll!ZwContinue
0905ffa0 791f59f6 clr!Thread::intermediateThreadProc+0x39 , calling clr!_alloca_probe_16
0905ffb4 7c80b729 kernel32!BaseThreadStart+0x37

The output of !clrstack: 
0:023> !clrstack
OS Thread Id: 0x5d0 (23)
Child SP IP       Call Site
0905f6bc 7c90e514 [GCFrame: 0905f6bc] 
0905f980 7c90e514 [DebuggerU2MCatchHandlerFrame: 0905f980]

The output of k:

0:023> k
ChildEBP RetAddr
0905a004 7c90d18a ntdll!KiFastSystemCallRet
0905a008 7c8094e5 ntdll!NtCreateSection+0xc
0905a014 00000000 kernel32!CreateFileMappingW+0x10b
Stephane Rolland
  • 38,876
  • 35
  • 121
  • 169
  • Some of those offsets are abnormally large, which suggests that you don't have the right symbols loaded. Or calls to dynamically generated code. DbgHelp maps instruction pointers to functions by looking for the last symbol before the indicated location -- it doesn't know if the indicated location is actually part of that function, or part of a code page for which it doesn't have symbols. – Ben Voigt Jun 12 '15 at 18:46
  • Yes there is C# generated code, our business code has been generated in this case. And there's no symbols for this dll as far as I know. – Stephane Rolland Jun 12 '15 at 18:47
  • What do you get from `k` (the native stack trace) and from `!CLRStack` ? – Ben Voigt Jun 12 '15 at 18:48
  • `clrstack` output is from a different thread – Ben Voigt Jun 12 '15 at 18:58
  • I have update with the info from the same dump file. – Stephane Rolland Jun 12 '15 at 19:03
  • Ok, it looks like the transition from managed code occurred many call frames earlier. – Ben Voigt Jun 12 '15 at 19:05
  • And the first two lines (at the bottom of the !dumpstack) don't look like the starting problem ? `0905fca8 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog 0905fd18 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog ` – Stephane Rolland Jun 12 '15 at 19:13
  • I don't trust the "calling blah" portion of the output. I think it's looking at the instruction immediately before the return address on the stack, to help debug code that uses tailcalls. But in this case I don't think it translated the call target correctly to a name. – Ben Voigt Jun 12 '15 at 19:29
  • I think you're running into the same problem as http://voneinem-windbg.blogspot.com/2009/02/keeping-pearl.html What does the "Calls" window show? – Ben Voigt Jun 12 '15 at 19:33

0 Answers0