dotnet clr: Here's a dump of one of the SEHExceptions:

Name: System.Runtime.InteropServices.SEHException
MethodTable 0x79c2b0ec
EEClass 0x79c2b16c
Size 64(0x40) bytes
GC Generation: 0
mdToken: 0x020002f6
(c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll)
FieldDesc*: 0x00000000
MT Field Offset Type Attr Value
Name
0x79b947ac 0x400001d 0x4 CLASS instance 0x00000000
_className
0x79b947ac 0x400001e 0x8 CLASS instance 0x00000000
_exceptionMethod
0x79b947ac 0x400001f 0xc CLASS instance 0x00000000
_exceptionMethodString
0x79b947ac 0x4000020 0x10 CLASS instance 0x00ba905c
_message
0x79b947ac 0x4000021 0x14 CLASS instance 0x00000000
_innerException
0x79b947ac 0x4000022 0x18 CLASS instance 0x00000000
_helpURL
0x79b947ac 0x4000023 0x1c CLASS instance 0x00000000
_stackTrace
0x79b947ac 0x4000024 0x20 CLASS instance 0x00000000
_stackTraceString
0x79b947ac 0x4000025 0x24 CLASS instance 0x00000000
_remoteStackTraceString
0x79b947ac 0x4000026 0x2c System.Int32 instance 0
_remoteStackIndex
0x79b947ac 0x4000027 0x30 System.Int32 instance -2147467259
_HResult
0x79b947ac 0x4000028 0x28 CLASS instance 0x00000000
_source
0x79b947ac 0x4000029 0x34 System.Int32 instance 55391628
_xptrs
0x79b947ac 0x400002a 0x38 System.Int32 instance -1073741818
_xcode
-----------------
Exception 00bb1438 in MT 79c2b0ec:
System.Runtime.InteropServices.SEHException
_message: External component has thrown an exception.


So that's C0000006? STATUS_IN_PAGE_ERROR? Why would this lead to a stack
overflow exception? Is there anything we can do to work around the issue?
.... other than get a better network ;)


Here's the full output of the kf command:

0:004> kf
Memory ChildEBP RetAddr
034d2a6c 7c90e9ab ntdll!KiFastSystemCallRet
4 034d2a70 7c8094f2 ntdll!ZwWaitForMultipleObjects+0xc
9c 034d2b0c 7c809c86 KERNEL32!WaitForMultipleObjectsEx+0x12c
1c 034d2b28 793a0ce8 KERNEL32!WaitForMultipleObjects+0x18
2c 034d2b54 793a34bc mscorwks!Debugger::EnsureDebuggerAttached+0x64
28 034d2b7c 793a3736 mscorwks!Debugger::SendException+0xcf
24 034d2ba0 792ae653
mscorwks!Debugger::LastChanceManagedException+0xb6
24 034d2bc4 792540b4 mscorwks!FailFast+0xb0
34 034d2bf8 7923870d mscorwks!GetPrevSEHRecord+0x791
18 034d2c10 792ae59d mscorwks!COMPlusFrameHandler+0x3d
1c 034d2c2c 7c9037bf mscorwks!COMPlusNestedExceptionHandler+0x57
24 034d2c50 7c90378b ntdll!ExecuteHandler2+0x26
b0 034d2d00 7c90eafa ntdll!ExecuteHandler+0x24
0 034d2d00 791b2ecb ntdll!KiUserExceptionDispatcher+0xe
480 034d3180 791d6a13 mscorwks!_SEH_prolog
324 034d34a4 79238c4a mscorwks!Thread::StackWalkFrames+0x8b
1c 034d34c0 79237510 mscorwks!LookForHandler+0x63
e8 034d35a8 79238de4 mscorwks!GetPrevSEHRecord+0x427
34 034d35dc 7923870d mscorwks!GetPrevSEHRecord+0x7d2
18 034d35f4 792ae59d mscorwks!COMPlusFrameHandler+0x3d

As for the dump, I can get a dump as long as I don't use "f", and "h"
generates a warning. I'm not sure why it would continue to complain about
being unable to read from the specified device after the network
connectivity has been restored, however.

Thanks for your assistance.

Regards,
Matt Garven


[quoted text, click to view]

We're receiving a StackOverflowException intermittently. I've attached with
WinDbg and provided some of the stack below (you can see the repeating
pattern that eventually causes the stack overflow):

0:004> !DumpStack 035cc9d8
Thread 4
Current frame: ntdll!KiFastSystemCallRet
ChildEBP RetAddr Caller,Callee
035cc9e0 799ac9e0 (MethodDesc 0x79bcd2f8 +0x38
System.Resources.ResourceManager.InternalGetResourceSet), calling
mscorwks!JIT_ChkCastClass
035cc9f8 799b01d0 (MethodDesc 0x79bcdce8 +0x20
System.Resources.RuntimeResourceSet.GetString)
035cc9fc 799b01dd (MethodDesc 0x79bcdce8 +0x2d
System.Resources.RuntimeResourceSet.GetString), calling
mscorwks!JIT_ChkCastClass
035cca18 799ac920 (MethodDesc 0x79bb4530 +0x10
System.Globalization.CultureInfo.get_UserDefaultUICulture), calling 003f22d0
035cca20 791b1b3a mscorwks!JIT_MonExit+0xf, calling 008f1e90
035cca28 799ac8a1 (MethodDesc 0x79bcd388 +0x141
System.Resources.ResourceManager.GetString), calling mscorwks!JIT_MonExit
035cca54 791b1b3a mscorwks!JIT_MonExit+0xf, calling 008f1e90
035cca5c 799b329e (MethodDesc 0x79b9a220 +0xce
System.Environment.GetResourceString), calling mscorwks!JIT_MonExit
035cca90 79aa16cb (MethodDesc 0x79c2b1e8 +0x1b
System.Runtime.InteropServices.SEHException..ctor), calling (MethodDesc
0x79b949d8 System.Exception..ctor)
035cca98 791d94bc mscorwks!CallDescrWorker+0x30
035ccaa0 791ed194 mscorwks!MethodDesc::CallDescr+0x1b8, calling
mscorwks!CallDescrWorker
035ccae0 791ed086 mscorwks!MethodDesc::CallDescr+0x79, calling
mscorwks!MetaSig::SizeOfActualFixedArgStack
035ccae4 791ed1e7 mscorwks!MethodDesc::CallDescr+0x20b, calling
mscorwks!__security_check_cookie
035ccbcc 7c9106eb ntdll!RtlAllocateHeap+0xeac, calling ntdll!_SEH_epilog
035ccbd0 7c809a0f KERNEL32!LocalAlloc+0x58, calling ntdll!RtlAllocateHeap
035ccbdc 7c809a20 KERNEL32!LocalAlloc+0x168, calling KERNEL32!_SEH_epilog
035ccbec 791bdf08 mscorwks!FieldDesc::SetInstanceField+0xff, calling
mscorwks!FieldDesc::GetSize
035ccc0c 79238c4a mscorwks!LookForHandler+0x63, calling
mscorwks!Thread::StackWalkFrames
035ccc28 79237510 mscorwks!GetPrevSEHRecord+0x427, calling
mscorwks!LookForHandler
035ccd10 79238de4 mscorwks!GetPrevSEHRecord+0x7d2, calling
mscorwks!GetPrevSEHRecord+0x2c
035ccd44 7923870d mscorwks!COMPlusFrameHandler+0x3d, calling
mscorwks!GetPrevSEHRecord+0x56d
035ccd5c 792ae59d mscorwks!COMPlusNestedExceptionHandler+0x57, calling
mscorwks!COMPlusFrameHandler
035ccd78 7c9037bf ntdll!ExecuteHandler2+0x26
035ccd9c 7c90378b ntdll!ExecuteHandler+0x24, calling ntdll!ExecuteHandler2
035ccdc0 7c937860 ntdll!RtlDispatchException+0xb1, calling
ntdll!RtlpExecuteHandlerForException
035cce4c 7c90eafa ntdll!KiUserExceptionDispatcher+0xe, calling
ntdll!RtlDispatchException
035cd150 791dc99a
mscorwks!CMiniMdTemplate<CMiniMd>::getSignatureOfMethod+0x23 ====> Exception
cxr@35cce84
035ccebc 791b3000 mscorwks!WszGetVersionEx+0x9c, calling
KERNEL32!GetVersionExW
035ccee0 7c910732 ntdll!RtlpAllocateFromHeapLookaside+0x42, calling
ntdll!_SEH_epilog
035ccf2c 791b4b81 mscorwks!MetaDataTracker::NoteAccess+0xc2, calling
mscorwks!_SEH_epilog
035ccf70 791b3000 mscorwks!WszGetVersionEx+0x9c, calling
KERNEL32!GetVersionExW
035ccfac 7c910732 ntdll!RtlpAllocateFromHeapLookaside+0x42, calling
ntdll!_SEH_epilog
035cd02c 791d7261 mscorwks!SigPointer::SkipExactlyOne+0x72, calling
mscorwks!CorSigUncompressToken
035cd050 791b66a1 mscorwks!StubLinker::EmitBytes+0x53, calling
MSVCR71!memcpy
035cd074 791b5b7e mscorwks!CorSigUncompressToken+0x1c, calling
mscorwks!CorSigUncompressBigData
035cd080 791d7261 mscorwks!SigPointer::SkipExactlyOne+0x72, calling
mscorwks!CorSigUncompressToken
035cd0a4 791dcd20 mscorwks!MetaSig::SizeOfActualFixedArgStack+0xc9, calling
mscorwks!MetaSig::NextArgNormalized
035cd0b0 791dcd7a mscorwks!MetaSig::SizeOfActualFixedArgStack+0xf2, calling
mscorwks!__security_check_cookie
035cd13c 7c9106eb ntdll!RtlAllocateHeap+0xeac, calling ntdll!_SEH_epilog
035cd140 7c809a0f KERNEL32!LocalAlloc+0x58, calling ntdll!RtlAllocateHeap
035cd15c 791dc9e4 mscorwks!MDInternalRO::GetSigOfMethodDef+0x2b, calling
mscorwks!CMiniMdTemplate<CMiniMd>::getSignatureOfMethod
035cd16c 791dc8f7 mscorwks!MethodDesc::GetSig+0x4c
035cd184 00976860 (stub for
CrikeyMonitor.Client.IdleDatLauncher.LaunchDat), calling 008f2f50
035cd18c 791dcdbe mscorwks!MethodDesc::CbStackPop+0x1d, calling
mscorwks!MethodDesc::GetSig
035cd198 791dced5 mscorwks!FramedMethodFrame::UpdateRegDisplay+0x4b, calling
mscorwks!MethodDesc::CbStackPop
035cd1a8 00976860 (stub for
CrikeyMonitor.Client.IdleDatLauncher.LaunchDat), calling 008f2f50
035cd1b0 791d6b62 mscorwks!Thread::StackWalkFramesEx+0x39f
035cd1d0 7c915041 ntdll!bsearch+0x42
035cd214 7c9155c9 ntdll!RtlpFindUnicodeStringInSection+0x7b, calling
ntdll!RtlHashUnicodeString
035cd254 7c91554a ntdll!RtlFindNextActivationContextSection+0x46, calling
ntdll!RtlpFindNextActivationContextSection
035cd274 7c9153f5 ntdll!RtlFindActivationContextSectionString+0xde, calling
ntdll!RtlFindNextActivationContextSection
035cd2c4 7c910732 ntdll!RtlpAllocateFromHeapLookaside+0x42, calling
ntdll!_SEH_epilog
035cd2fc 00976860 (stub for
CrikeyMonitor.Client.IdleDatLauncher.LaunchDat), calling 008f2f50
035cd324 791d6a13 mscorwks!Thread::StackWalkFrames+0x8b, calling
mscorwks!Thread::StackWalkFramesEx
035cd37c 7c919dad ntdll!RtlGetVersion+0x70, calling ntdll!wcsncpy
035cd3a4 799a44ea (MethodDesc 0x79ba9b70 +0x22
System.Collections.Hashtable.KeyEquals)
035cd3b0 7c910732 ntdll!RtlpAllocateFromHeapLookaside+0x42, calling
ntdll!_SEH_epilog
035cd3dc 7c911414 ntdll!RtlAllocateHeap+0x6d9, calling
ntdll!RtlpUpdateIndexRemoveBlock
035cd3e0 7c911596 ntdll!RtlAllocateHeap+0x43d, calling
ntdll!RtlLeaveCriticalSection
035cd3e4 7c9106eb ntdll!RtlAllocateHeap+0xeac, calling ntdll!_SEH_epilog
035cd41c 799ac9e0 (MethodDesc 0x79bcd2f8 +0x38
System.Resources.ResourceManager.InternalGetResourceSet), calling
mscorwks!JIT_ChkCastClass
035cd434 799b01d0 (MethodDesc 0x79bcdce8 +0x20
System.Resources.RuntimeResourceSet.GetString)
035cd438 799b01dd (MethodDesc 0x79bcdce8 +0x2d
System.Resources.RuntimeResourceSet.GetString), calling
mscorwks!JIT_ChkCastClass
035cd454 799ac920 (MethodDesc 0x79bb4530 +0x10
System.Globalization.CultureInfo.get_UserDefaultUICulture), calling 003f22d0
035cd45c 791b1b3a mscorwks!JIT_MonExit+0xf, calling 008f1e90
035cd464 799ac8a1 (MethodDesc 0x79bcd388 +0x141
System.Resources.ResourceManager.GetString), calling mscorwks!JIT_MonExit
035cd480 7c910732 ntdll!RtlpAllocateFromHeapLookaside+0x42, calling
ntdll!_SEH_epilog
035cd490 791b1b3a mscorwks!JIT_MonExit+0xf, calling 008f1e90
035cd498 799b329e (MethodDesc 0x79b9a220 +0xce
System.Environment.GetResourceString), calling mscorwks!JIT_MonExit
035cd4cc 79aa16cb (MethodDesc 0x79c2b1e8 +0x1b

What is the exception code in those SEHExceptions (you can use !do
to dump it)?

!DumpStack is a raw stack dump similar to 'dds esp' so it shows a lot
of bogus frames. 'kf' would probably give you a better idea of how the
overflow happened.

To create a dump, you can try excluding pieces of information that could
be backed by remote files. Start with .dump /m. If that works, try adding
other options one by one (F, h, u, t, w, d etc).

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

[quoted text, click to view]

[quoted text, click to view]

Looks like CLR tries to unwind the stack, calls a managed exception handler
and generates a nested exception because the handler cannot be paged in.
The process then repeats itself.

In the unmanaged world you deal with this by using the /swaprun linker
option:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.swaprun.asp

I'm not sure if this will work for managed code but you could try something
like "link /edit /swaprun:net my_app.exe".

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

Hi Pavel,

I suppose for now I'll make the process copy itself to the local disk temp
path and relaunch.

I'm not sure how the /swaprun option would help us as this is a deployed
executable.

This problem caused a reasonable amount of headscratching for us as
reproducing it was difficult and more often than not the process seemed to
quit and just leave us with the vs7jit process. I was quite relieved when it
occurred on my machine and I was able to debug it. Thanks for the tip on
looking at the _xcode field in the SEHException, that helped us finally nail
this problem.

That said, it would be nice if the CLR could either handle this or provide a
more useful error message. I'm sure this would require considerable work,
however running from a network drive seems like something you would expect
to just work - at least in the managed world ;)

Thanks again.

Regards,
Matt Garven

[quoted text, click to view]

[quoted text, click to view]


Well if parts of the process cannot be paged in there's no way
it could "just work". I guess it could be failing in a more predictable
way but I'm not sure whether the current behavior constitues a bug
or not.

--
This posting is provided "AS IS" with no warranties, and confers no
rights.