I've installed IE 9 last week and since, my c# .net application crashes about 20% of times. The debugger is unable to show something useful besides stopping at Program.cs Application.Run(new MyMainForm()); , btw the main form was already shown, so it's not that it's something in construction on main form.
I have Windows7.
The exception thrown is:
"An unhandled exception of type 'System.ArgumentException' occurred in System.Windows.Forms.dll
Additional information: Value does not fall within the expected range.
Screen shot of callstack -> http://img861.imageshack.us/f/ie9v.png/
When running outside of debugger, this info is shown:
Problem signature:
Problem Event Name: APPCRASH
Application Name: myexe.exe
Application Version: 6.7.6.0
Application Timestamp: 4d7fdffd
Fault Module Name: mshtml.dll
Fault Module Version: 9.0.8112.16421
Fault Module Timestamp: 4d76266c
Exception Code: c0000005
Exception Offset: 0012c848
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1037
And sometimes instead of mshtml.dll it says StackHash_f09d
Problem Event Name: APPCRASH
Application Name: myexe.exe
Application Version: 6.7.6.0
Application Timestamp: 4d7fdffd
Fault Module Name: StackHash_f09d
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 00000000
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1037
Thanks in advance
Edited:
That's what I see in windbg, with symbols:
0:000> kb
ChildEBP RetAddr Args to Child
0020eda4 64d54f83 0566c988 00001012 00000000 mshtml!CDoc::ReduceMemoryPressureTask+0x1a
0020edb4 64d54f2c c6b991e4 0020ee78 00000113 mshtml!GWYieldToMsgOnCurrentThread+0x17b
0020edfc 770086ef 00192392 00000012 0000201b mshtml!GlobalWndProc+0x1f2
0020ee28 77008876 64d54afe 00192392 00000113 USER32!InternalCallWinProc+0x23
0020eea0 770089b5 00000000 64d54afe 00192392 USER32!UserCallWinProcCheckWow+0x14b
0020ef00 77008e9c 64d54afe 00000000 0020ef2c USER32!DispatchMessageWorker+0x35e
0020ef10 03b54726 0020ef9c fa69a961 00000000 USER32!DispatchMessageW+0xf
*** WARNING: Unable to verify checksum for C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\f92c882fd4e7005c005e208daa04c28d\System.Windows.Forms.ni.dll
WARNING: Frame IP not in any known module. Following frames may be wrong.
0020ef2c 5af78aee 01b743e4 00000001 01ac95cc 0x3b54726
0020efe0 5af78757 00000000 ffffffff 00000000 System_Windows_Forms_ni+0x208aee
0020f038 5af785a1 01b6c610 1f3a000e 00000000 System_Windows_Forms_ni+0x208757
0020f068 5af35911 01bb7d84 0020f10c 003b73d8 System_Windows_Forms_ni+0x2085a1
0020f0e0 6f221b5c 015b1141 00000001 0020f170 System_Windows_Forms_ni+0x1c5911
0020f0f0 6f232209 0020f1c0 00000000 0020f190 mscorwks!CallDescrWorker+0x33
0020f170 6f246511 0020f1c0 00000000 0020f190 mscorwks!CallDescrWorkerWithHandler+0xa3
0020f2b4 6f246544 0032c040 0020f380 0020f34c mscorwks!MethodDesc::CallDescr+0x19c
0020f2d0 6f246562 0032c040 0020f380 0020f34c mscorwks!MethodDesc::CallTargetWorker+0x1f
0020f2e8 6f2b0c45 0020f34c d847bc11 00000000 mscorwks!MethodDescCallSite::CallWithValueTypes+0x1a
0020f44c 6f2b0b65 003239c0 00000001 0020f488 mscorwks!ClassLoader::RunMain+0x223
0020f6b4 6f2b10b5 00000000 d847b3d9 00000001 mscorwks!Assembly::ExecuteMainMethod+0xa6
0020fb84 6f2b129f 013a0000 00000000 d847b389 mscorwks!SystemDomain::ExecuteMainMethod+0x456
=====UPDATE(I'm not sure, if I'm supposed to post it as "Answer your question")============
Thanks to everyone trying to help, I appreciate it.
Being desperate, I started to remove pieces of code to understand which part of my code affects it(we use webrowser control in many forms). After removing call to LoginForm which also uses webrowser control, the problem disappeared.
The login form hosts webrowser control, it navigates to certain url, for example /login.php and if user is already logged-in, method UserLoggedIn inside form is invoked from html using ObjectForScripting. When UserLoggedIn was called, we were calling Close() to close form if the LoginForm was shown. Even though LoginForm was doing all this, we weren't always showing it. We were, showing it only if after X seconds UserLoggedIn() was not called(i.e user needs to login).
For some reason, and thanks to MS for making us able to debug into .net sources, when we were calling Close, and the form was not Visible it was actually disposing the form and all it's children because IsHandleCreated was false. Now, the Close was called from UserLoggedIn(), which is an event fired by the browser control(the callstack shows ieframe.dll, mshtml.dll etc) , so the webbrowser object was being destoyed while being called from.
The hacky way to resolve this, was to call Close, only if form was Visible. BTW, I don't know, why IsHandleCreated is false, if we don't show the form. I tried to reproduce it, by writing a sample that creates a form, which is not shown, but it's IsHandleCreated is true.
---- from Forms.cs -----
public void Close()
{
if (GetState(STATE_CREATINGHANDLE))
throw new InvalidOperationException(SR.GetString(SR.ClosingWhileCreatingHandle, "Close"));
if (IsHandleCreated) {
closeReason = CloseReason.UserClosing;
SendMessage(NativeMethods.WM_CLOSE, 0, 0);
}
else{
// MSDN: When a form is closed, all resources created within the object are closed and the form is disposed.
// For MDI child: MdiChildren collection gets updated (VSWhidbey# 368642 & 93550)
Dispose(); // THIS WAS CALLED WHEN FORM WAS NOT VISIBLE
}
}
Educated speculation to get you started- timers use thread pool threads, which are MTA. If I had to guess I'd say that it could be related to that, since activex controls can only be safely instantiated from STA threads. Perhaps try creating a thread manually rather than using the timer thread?
browser.Navigate("xxx") is called from timer
What kind of timer are you using? If the timer fire callback happens on another thread, and you are calling methods on the browser object, then you are opening yourself up random crash likelyhood. Try setting Control.CheckForIllegalCrossThreadCalls = true; in your Main() method beofre running the Application.Run(...) method and see if when it crashes, you get a more "on point" error message or the same.
This crash happens when jscript.dll is incorrectly registered. The ReduceMemoryPressureTask method expects it to be loaded and causes a null dereference otherwise. A fix is to run regsvr32 jscript.dll on the affected machine. You can check for the error by looking at the loaded module list to see if jscript.dll is missing or not. This can be done either programatically or through Process Explorer.
The exception code c0000005 usually means that is a memory problem. Maybe it has to do with 32 and 64 bits areas of your application getting confused.
I would try to make your app run fully in 64, then fully 32, see what happens.
Try running as admin, see if that changes anything.
Also you should put try catches on the points where it makes sense, and rety whenever the error is found.
Well those are suggestions, so try it out and see if you can get us more info.
Good Luck!
There might be a reason, since the WinForms runs under STA , but the web browser requires MTA. Put a try-catch above the browser control and also check if there is r/w access voilation. As stated by oakcool
I've run in to problems with this, mostly due to privilege violations.
The program was running at administrator level and the browser was running at user level, or visa-versa.
Something to look into
i get the same error/crash since i got the ie9 installed. it only happens whenever there is a youtube movie on the page. than it hangs/crashes with the exact same window you get Jack Juiceson.
but behind the "Fault Module Name" i dont get mshtml.dll, i get a d3d9.dll or something like that. veryyyyy odd.
Related
I'm investigating a handle leak in a WCF service, running on .NET 4.6.2. The service runs fine but over time handle count keeps increasing, with thousands of Token type handles sitting around in the process. It seems memory is also leaking very slowly (likely related to the handle leak).
Edit: it looks like event and thread handles are also leaked.
Process Explorer shows that the suspect handles all have the same name:
DOMAIN\some.username$:183db90
and all share the same address.
I attached WinDbg to the process and ran !htrace -enable and then !htrace -diff some time later. This gave me a list of almost 2000 newly opened handles and native stack traces, like this one:
Handle = 0x000000000000b02c - OPEN
Thread ID = 0x000000000000484c, Process ID = 0x0000000000002cdc
0x00007ffc66e80b3a: ntdll!NtCreateEvent+0x000000000000000a
0x00007ffc64272ce8: KERNELBASE!CreateEventW+0x0000000000000084
0x00007ffc5b392e0a: clr!CLREventBase::CreateManualEvent+0x000000000000003a
0x00007ffc5b3935c7: clr!Thread::AllocHandles+0x000000000000007b
0x00007ffc5b3943c7: clr!Thread::CreateNewOSThread+0x000000000000007f
0x00007ffc5b394308: clr!Thread::CreateNewThread+0x0000000000000090
0x00007ffc5b394afb: clr!ThreadpoolMgr::CreateUnimpersonatedThread+0x00000000000000cb
0x00007ffc5b394baf: clr!ThreadpoolMgr::MaybeAddWorkingWorker+0x000000000000010c
0x00007ffc5b1d8c74: clr!ManagedPerAppDomainTPCount::SetAppDomainRequestsActive+0x0000000000000024
0x00007ffc5b1d8d27: clr!ThreadpoolMgr::SetAppDomainRequestsActive+0x000000000000003f
0x00007ffc5b1d8cae: clr!ThreadPoolNative::RequestWorkerThread+0x000000000000002f
0x00007ffc5a019028: mscorlib_ni+0x0000000000549028
0x00007ffc59f5f48f: mscorlib_ni+0x000000000048f48f
0x00007ffc59f5f3b9: mscorlib_ni+0x000000000048f3b9
Another stack trace (a large portion of the ~2000 new handles have this):
Handle = 0x000000000000a0c8 - OPEN
Thread ID = 0x0000000000003614, Process ID = 0x0000000000002cdc
0x00007ffc66e817aa: ntdll!NtOpenProcessToken+0x000000000000000a
0x00007ffc64272eba: KERNELBASE!OpenProcessToken+0x000000000000000a
0x00007ffc5a01aa9b: mscorlib_ni+0x000000000054aa9b
0x00007ffc5a002ebd: mscorlib_ni+0x0000000000532ebd
0x00007ffc5a002e68: mscorlib_ni+0x0000000000532e68
0x00007ffc5a002d40: mscorlib_ni+0x0000000000532d40
0x00007ffc5a0027c7: mscorlib_ni+0x00000000005327c7
0x00007ffbfbfb3d6a: +0x00007ffbfbfb3d6a
When I run the !handle 0 0 command in WinDbg, I get the following result:
21046 Handles
Type Count
None 4
Event 2635 **
Section 360
File 408
Directory 4
Mutant 9
Semaphore 121
Key 77
Token 16803 **
Thread 554 **
IoCompletion 8
Timer 3
TpWorkerFactory 2
ALPC Port 7
WaitCompletionPacket 51
The ones marked with ** are increasing over time, although at a different rate.
Edit 3:
I ran !dumpheap to see the number of Thread objects (unrelated classes removed):
!DumpHeap -stat -type System.Threading.Thread
Statistics:
MT Count TotalSize Class Name
00007ffc5a152bb0 745 71520 System.Threading.Thread
Active thread count fluctuates between 56 and 62 in Process Explorer as the process is handling some background tasks periodically.
Some of the stack traces are different but they're all native traces so I don't know what managed code triggered the handle creation. Is it possible to get the managed function call that's running on the newly created thread when Thread::CreateNewThread is called? I don't know what WinDbg command I'd use for this.
Note:
I cannot attach sample code to the question because the WCF service loads hundreds of DLL-s, most of which are built from many source files - I have some very vague suspicions in what major area this may come from but I don't know any details to show an MCVE.
Edit: after Harry Johnston's comments below, I noticed that thread handle count is also increasing - I overlooked this earlier because of the high number of token handles.
I've got a .NET application that pinvokes several libraries, all 32 bit (the application is 32 bit as well). I recently started getting crash bugs that occurred when the GC started freeing memory, and when I attached I saw that it was an access violation. After some web searches, I got myself set up with gflags and windbg, and was able to get the actual problem :
===========================================================
VERIFIER STOP 0000000F: pid 0x9650: corrupted suffix pattern
001B1000 : Heap handle
20A5F008 : Heap block
00000006 : Block size
20A5F00E : corruption address
===========================================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.
===========================================================
After doing some more reading, I was able to get a stack trace :
0:009> !heap -p -a 20A5F008
address 20a5f008 found in
_HEAP # f420000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
20a5efe0 0008 0000 [00] 20a5f008 00006 - (busy)
Trace: 0a94
60cba6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
60cb8f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
77e00d96 ntdll!RtlDebugAllocateHeap+0x00000030
77dbaf0d ntdll!RtlpAllocateHeap+0x000000c4
77d63cfe ntdll!RtlAllocateHeap+0x0000023a
60cccb62 verifier!AVrfpRtlAllocateHeap+0x00000092
7666ea43 ole32!CRetailMalloc_Alloc+0x00000016
7666ea5f ole32!CoTaskMemAlloc+0x00000013
6c40b25d clr!MngdNativeArrayMarshaler::ConvertSpaceToNative+0x000000bd
... and some more detailed information on the block entry :
0:009> !heap -i 20a5f008
Detailed information for block entry 20a5f008
Assumed heap : 0x0f610000 (Use !heap -i NewHeapHandle to change)
Header content : 0x00000000 0x00000001
Owning segment : 0x0f610000 (offset 0)
Block flags : 0x0 (free )
Total block size : 0x0 units (0x0 bytes)
Previous block size: 0xb4e4 units (0x5a720 bytes)
Block CRC : OK - 0x0
List corrupted: (Blink->Flink = 00000000) != (Block = 20a5f010)
Free list entry : CORRUPTED
Previous block : 0x20a048e8
Next block : 0x20a5f008
I'm kind of stuck with this data. Unfortunately, ConvertSpaceToNative isn't an illuminating call, since that encompasses... pretty much every unmanaged allocation request. I've tried branching out further to find the information I'd need to trace it back to the offending call and spent days looking through documentation, but am not finding a way to determine the actual source of the corruption. I've tried setting break points and stepping through, but I can't find a way to verify the contents of the heap manually that actually works - it always reports that everything is okay. It also seems to me that I should be able to get the application to halt immediately by turning on full page heaps, but it still looks like it's not halting until the free call (this is the call stack when execution halts) :
0:009> kL
ChildEBP RetAddr
2354ecac 60cb9df2 verifier!VerifierStopMessage+0x1f8
2354ed10 60cba22a verifier!AVrfpDphReportCorruptedBlock+0x1c2
2354ed6c 60cba742 verifier!AVrfpDphCheckNormalHeapBlock+0x11a
2354ed8c 60cb90d3 verifier!AVrfpDphNormalHeapFree+0x22
2354edb0 77e01564 verifier!AVrfDebugPageHeapFree+0xe3
2354edf8 77dbac29 ntdll!RtlDebugFreeHeap+0x2f
2354eeec 77d634a2 ntdll!RtlpFreeHeap+0x5d
2354ef0c 60cccc4f ntdll!RtlFreeHeap+0x142
2354ef54 76676e6a verifier!AVrfpRtlFreeHeap+0x86
2354ef68 76676f54 ole32!CRetailMalloc_Free+0x1c
2354ef78 6c40b346 ole32!CoTaskMemFree+0x13
2354f008 231f7e8a clr!MngdNativeArrayMarshaler::ClearNative+0x78
WARNING: Frame IP not in any known module. Following frames may be wrong.
2354f08c 231f6442 0x231f7e8a
2354f154 231f5a7b 0x231f6442
2354f264 231f572b 0x231f5a7b
2354f288 231f56a4 0x231f572b
2354f2a4 231f7b3e 0x231f56a4
2354f330 231f207b 0x231f7b3e
2354f3b4 1edf60e0 0x231f207b
*** WARNING: Unable to verify checksum for C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\045c9588954c3662d542b53f4462268b\mscorlib.ni.dll
2354f850 6a746ed4 0x1edf60e0
2354f85c 6a724157 mscorlib_ni+0x386ed4
2354f8c0 6a724096 mscorlib_ni+0x364157
2354f8d4 6a724051 mscorlib_ni+0x364096
2354f8f0 6a691cd2 mscorlib_ni+0x364051
2354f908 6c353e22 mscorlib_ni+0x2d1cd2
2354f914 6c363355 clr!CallDescrWorkerInternal+0x34
2354f968 6c366d1f clr!CallDescrWorkerWithHandler+0x6b
2354f9e0 6c4d29d6 clr!MethodDescCallSite::CallTargetWorker+0x152
2354fb54 6c3c8357 clr!ThreadNative::KickOffThread_Worker+0x19d
2354fb68 6c3c83c5 clr!Thread::DoExtraWorkForFinalizer+0x1ca
2354fc10 6c3c8492 clr!Thread::DoExtraWorkForFinalizer+0x256
2354fc6c 6c3c84ff clr!Thread::DoExtraWorkForFinalizer+0x615
2354fc90 6c4d2ad8 clr!Thread::DoExtraWorkForFinalizer+0x6b2
2354fd14 6c3fb4ad clr!ThreadNative::KickOffThread+0x1d2
2354feb0 60cd11d3 clr!Thread::intermediateThreadProc+0x4d
2354fee8 75c6336a verifier!AVrfpStandardThreadFunction+0x2f
2354fef4 77d69f72 KERNEL32!BaseThreadInitThunk+0xe
2354ff34 77d69f45 ntdll!__RtlUserThreadStart+0x70
2354ff4c 00000000 ntdll!_RtlUserThreadStart+0x1b
I feel like it's supposed to be obvious what I ought to be doing now, but no avenue of investigation is turning up anything to move me towards resolving the bug.
I finally resolved this, and found that I had made one crucial mistake. With a corrupted suffix pattern, the error will come on a free attempt, which led me to believe that it was unlikely that the allocation would have come right before the free. This was not accurate. When dealing with corruption that occurs on free, barring further information, any allocation point is equally likely. In this case, the verifier halt was coming on freeing a parameter which had been incorrectly defined as a struct of shorts instead of as a struct of ints.
Here's the offending code:
[DllImport("gdi32.dll", CharSet = CharSet.Unicode)]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool GetCharABCWidths(IntPtr hdc, uint uFirstChar, uint uLastChar, [Out] ABC[] lpabc);
(This declaration is okay)
[StructLayout(LayoutKind.Sequential)]
public struct ABC
{
public short A;
public ushort B;
public short C;
}
(This is not okay, per the MSDN article on the ABC struct : http://msdn.microsoft.com/en-us/library/windows/desktop/dd162454(v=vs.85).aspx )
So, if you find yourself debugging memory corruption that halts on free, keep in mind: never discount the possibility that the memory being freed was incorrectly allocated to begin with... and mind those [Out] parameters on unmanaged calls!
We have a rich client application developed using WPF/C#.Net 4.0 which interops with in-house COM DLLs. Regular events are raised via this COM interface containing video data.
As part of the application we render video via Windows Media Foundation and have created interops to use Window Media Foundation. We have multiple WMF pipelines rendering different video at the same time.
The application runs for 6-8 hours rendering video. Private bytes remaining consistently steady during this time (say around 500-600MB).
At some point the application appears to hang, at this point private bytes increases very rapidly until the process consumes approximately 1.4GB of memory and crashes with an OutOfMemoryException.
We have reproduced this on 5 different workstations with different graphic cards (NVIDIA and ATI cards) and a mixture of Windows 7 32 and 64bit.
We have analyzed 3 dump files and found that the finalizer thread is waiting on a call to the ole32.GetToSTA() method. We are unable to determine what causes the finalizer thread to block and how to resolve this. I have pasted excerpts from three dumps we've been analyzing:
Dump 1)
Thread 2:ae0 is waiting on an STA thread efc
Thread 28:efc is calling a WaitForSingleObject. The handle it is waiting on is actually a thread handle 5ab4 which is thread id 14a4
Thread 130:14a4 has the following stack:
37f4fdf4 753776a6 ntdll!NtRemoveIoCompletion+0x15
37f4fe20 63301743 KERNELBASE!GetQueuedCompletionStatus+0x29
37f4fe74 6330d0db WMNetMgr!CNSIoCompletionPortNT::WaitAndServeCompletionsLoop+0x5e
37f4fe94 633199bf WMNetMgr!CNSIoCompletionPortNT::WaitAndServeCompletions+0x4c
37f4fecc 63312dbd WMNetMgr!CWorkThreadManager::CWorkerThread::ThreadMain+0xa2
37f4fed8 769b3677 WMNetMgr!CWMThread::ThreadFunc+0x3b
37f4fee4 77679f42 kernel32!BaseThreadInitThunk+0xe
37f4ff24 77679f15 ntdll!__RtlUserThreadStart+0x70
37f4ff3c 00000000 ntdll!_RtlUserThreadStart+0x1b
Dump2)
STA thread:
1127f474 75f80a91 ntdll!ZwWaitForSingleObject+0x15
1127f4e0 77411184 KERNELBASE!WaitForSingleObjectEx+0x98
1127f4f8 77411138 kernel32!WaitForSingleObjectExImplementation+0x75
1127f50c 63ae5f29 kernel32!WaitForSingleObject+0x12
1127f530 63a8eb2e WMNetMgr!CWMThread::Wait+0x78
1127f54c 63a8f128 WMNetMgr!CWorkThreadManager::CThreadPool::Shutdown+0x70
1127f568 63a76e10 WMNetMgr!CWorkThreadManager::Shutdown+0x34
1127f59c 63a76f2d WMNetMgr!CNSClientNetManagerHelper::Shutdown+0xdd
1127f5a4 63cd228e WMNetMgr!CNSClientNetManager::Shutdown+0x66
WARNING: Stack unwind information not available. Following frames may be wrong.
1127f5bc 63cd23a6 WMVCORE!WMCreateProfileManager+0xeef6
1127f5dc 63c573ca WMVCORE!WMCreateProfileManager+0xf00e
1127f5e8 63c62f18 WMVCORE!WMIsAvailableOffline+0x2ba3b
1127f618 63c19da6 WMVCORE!WMIsAvailableOffline+0x37589
1127f630 63c1aca2 WMVCORE!WMIsContentProtected+0x56e4
1127f63c 63c14bd7 WMVCORE!WMIsContentProtected+0x65e0
1127f650 113de6e8 WMVCORE!WMIsContentProtected+0x515
1127f660 113de513 wmp!CWMDRMReaderStub::CExternalStub::ShutdownInternalRefs+0x1d0
1127f674 113c1988 wmp!CWMDRMReaderStub::ExternalRelease+0x4f
1127f67c 1160a5b9 wmp!CWMDRMReaderStub::CExternalStub::Release+0x13
1127f6a4 1161745f wmp!CWMGraph::CleanupUpStream_selfprotected+0xbe
Finalizer thread is trying to switch to STA:
0126eccc 75f80a91 ntdll!ZwWaitForSingleObject+0x15
0126ed38 77411184 KERNELBASE!WaitForSingleObjectEx+0x98
0126ed50 77411138 kernel32!WaitForSingleObjectExImplementation+0x75
0126ed64 75d78907 kernel32!WaitForSingleObject+0x12
0126ed88 75e9a819 ole32!GetToSTA+0xad
Dump3)
The finalizer thread is in the GetToSTA call, so it is waiting for a COM object to free
Thread 29 is a COM object in the STA, and it is waiting on a critical section owned by thread 53 (1bf4)
Thread 53 is doing:
1cbcf990 76310a91 ntdll!ZwWaitForSingleObject+0x15
1cbcf9fc 74cb1184 KERNELBASE!WaitForSingleObjectEx+0x98
1cbcfa14 74cb1138 kernel32!WaitForSingleObjectExImplementation+0x75
1cbcfa28 65dfb6bb kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
1cbcfa48 74cb3677 wmp!Ordinal3000+0x53280
1cbcfa54 77029f42 kernel32!BaseThreadInitThunk+0xe
1cbcfa94 77029f15 ntdll!__RtlUserThreadStart+0x701cbcfaac 00000000 ntdll!_RtlUserThreadStart+0x1b
Any ideas on how we might resolve this issue?
Well, the finalizer thread is deadlocked. That will certainly result in an eventual OOM. We can't see the full stack trace for the finalizer thread but some odds that you'll see SwitchAptAndDispatchCall() and ReleaseRCWListInCorrectCtx() in the trace, indicating that it is trying to call IUnknown::Release() to release a COM object. And that object is apartment threaded so a thread switch is required to safely make the call.
I don't see any decent candidates in the stack traces you posted, possibly because you didn't get the right one or the thread is already busy shutting down due to the exception. Try to catch it earlier with a debugger break as soon as you see the virtual memory size climb.
The most common cause for a deadlock like this is violating the requirements for an STA thread. Which state that it must never block and must pump a message loop. The never-block requirement is typically easily met in a .NET program, the CLR will pump a message loop when necessary when you use the lock statement or a WaitHandle.WaitXxx() call. It is however very common to forget to pump a message loop, especially since doing so is kinda painful. Application.Run() is required.
after running the .exe thought WinDBG, this was the exception information provided by pressing "k" when the exception occured:
ChildEBP RetAddr
0012e2f4 6f9fbb1c KERNELBASE!RaiseException+0x58
0012e354 6fba88f4 mscorwks!RaiseTheExceptionInternalOnly+0x2a8
0012e36c 6fba8966 mscorwks!RaiseTheException+0x4e
0012e394 6fba8997 mscorwks!RaiseTheException+0xc0
0012e3c0 6fba89a5 mscorwks!RealCOMPlusThrow+0x30
0012e3d0 6fac7ffe mscorwks!RealCOMPlusThrow+0xd
0012e8c8 6fa9d308 mscorwks!MethodTable::DoRunClassInitThrowing+0x44c
0012e914 6f9f8b9b mscorwks!DomainFile::Activate+0x226
0012e920 6f9cc537 mscorwks!DomainFile::DoIncrementalLoad+0xb4
0012e9a4 6f9cc43e mscorwks!AppDomain::TryIncrementalLoad+0x97
0012e9f4 6f9cd449 mscorwks!AppDomain::LoadDomainFile+0x19d
0012ea6c 6fb40e1a mscorwks!AppDomain::LoadDomainAssembly+0x116
0012eab0 6fb148c4 mscorwks!AppDomain::LoadExplicitAssembly+0x43
0012ed24 6fb167be mscorwks!ExecuteDLLForAttach+0x109
0012edd4 6fb16e9b mscorwks!ExecuteDLL+0x197
0012ee20 704c71f8 mscorwks!CorDllMainForThunk+0x8d
0012ee38 704ca1fe MSCOREE!CorDllMainWorkerForThunk+0x50
0012ee48 704bb2dc MSCOREE!VTableBootstrapThunkInitHelper+0x1b
0012eec8 7726519a MSCOREE!VTableBootstrapThunkInitHelperStub+0xc
WARNING: Stack unwind information not available. Following frames may be wrong.
0012eed0 7726517e ntdll!RtlpNtMakeTemporaryKey+0x43d6
0012eed4 770116fc ntdll!RtlpNtMakeTemporaryKey+0x43ba
0012ef10 77227d96 RPCRT4!DG_CCALL::DispatchPacket+0x1e3
0012ef14 014b1628 ntdll!RtlTimeToElapsedTimeFields+0xe902
0012ef18 00000000 0x14b1628
Does anyone knows what does this mean? And how can I solve it?
If it is a 3.5 or lower .NET then you have to load sos by calling ".loadby sos mscorwks". If it is a 4.0 then you have to use ".loadby sos clr".
What you're seeing is the unmanaged stack that's handling a managed exception. I suggest you do the following:
.load sos
!CLRStack
The first line will load SOS.dll, which allows for debugging of managed code. The second will print the managed stack trace. You can also use !help to see what other commands are available. For more information, see this MSDN article: http://msdn.microsoft.com/en-us/library/yy6d2sxs.aspx.
I've got a WebBrowser control on my page. To fire some javascript on a page displayed in the browser control, I call this.myBrowser.Document.InvokeScript("Test");
This works on my dev box with IE7, but on a seperate test machine I get the following error:
Exception Type: System.InvalidCastException
Message: Specified cast is not valid.
Source: System.Windows.Forms
Stack Trace:
at System.Windows.Forms.UnsafeNativeMethods.IHTMLDocument2.GetLocation()
at System.Windows.Forms.WebBrowser.get_Document()
at InteriorHealth.EmbeddedBrowser.frmMain.CardRead(String strData) in E:\Develop\TestProject\frmMain.cs:line 265
at MyTest.frmMain.prtCardReader_DataReceived(Object sender, SerialDataReceivedEventArgs e) in E:\Develop\TestProject\frmMain.cs:line 355
The test machine is running IE6. Although I'm not sure, I'm speculating that the difference in IE versions may be the reason for the error. Does this sound right? How do I work around this?
Line 265 of frmMain.cs is:
this.webKiosk.Document.InvokeScript(ConfigurationState.CardReader.Error.FireJavaScriptMethod);
Line 355 of frmMain.cs is:
CardRead(strCardData_m);
I think the exception is being thrown by the Document property call on the WebBrowser object.
Figured it out. My call was being invoked from a serial port data received event, which doesn't execute on the main GUI thread. I used a this.Invoke() method call to get my code to execute on the main GUI thread, all is good now!