0

I have a 32 bit app website running on IIS 7.5 that is randomly crashing and provides a hdmp file under the WER directory. Problem is the dump file is around 3GB and can't be read by the 32 bit Windbg tool as it gives an error that it is too big. The 64 bit version of Windbg will read it but when it comes to running any commands, it says it can't run as the crash dump is for a 32 bit app.

Is there a way to read this dump file or any way to make it smaller for future crashes? Is there a size limit on 32 bit crash dumps that Windbg can analyse ie 2GB? I'm a sys admin rather than a web developer, so this is all new to me.

UPDATE

Got some kind of output from !Analyse -v, although symbols haven't loaded properly direct from MS:

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  w3wp.exe

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

MANAGED_STACK: !dumpstack -EE
SOS does not support the current target architecture.

MANAGED_BITNESS_MISMATCH: 
Managed code needs matching platform of sos.dll for proper analysis. Use 'x86' debugger.

PRIMARY_PROBLEM_CLASS:  WRONG_SYMBOLS

BUGCHECK_STR:  APPLICATION_FAULT_WRONG_SYMBOLS_CLR_EXCEPTION

LAST_CONTROL_TRANSFER:  from 72ec615a to 756fb727

STACK_TEXT:  
1cdef038 72ec615a e0434352 00000001 00000005 KERNELBASE!RaiseException+0x58
1cdef0dc 72fd1bec 00000000 10f354c4 1cdef100 clr!RaiseTheExceptionInternalOnly+0x276
1cdef0f4 72fd1e1d 00000004 1cdef26c 72ec637e clr!RaiseTheException+0x86
1cdef11c 72fd1e4d 00000004 00000004 00000000 clr!RaiseTheExceptionInternalOnly+0x30a
1cdef150 72faef2d 8843cf04 00000000 1b8f51c0 clr!RealCOMPlusThrow+0x2f
1cdef278 72fae48a 00000000 1cdef2bc 8843ce3c clr!Thread::RaiseCrossContextException+0x37b
1cdef340 72e57c22 00000002 01e57c43 00000000 clr!Thread::DoADCallBack+0x2d3
1cdef398 00b4a9bd ffffffff 00b4a940 1cdef3d4 clr!UM2MDoADCallBack+0x92
WARNING: Frame IP not in any known module. Following frames may be wrong.
1cdef3cc 72cf9651 00000000 00c4f1c4 0000000e 0xb4a9bd
1cdef3f0 72cfa3b4 733e81f0 72cfa382 1cdef448 webengine4!W3_MGD_HANDLER::ProcessNotification+0x58
1cdef400 72e4de98 00c4f1c4 8843c96c 1cdef479 webengine4!ProcessNotificationCallback+0x32
1cdef448 72e519b1 1cdef479 1cdef47b 000b001c clr!UnManagedPerAppDomainTPCount::DispatchWorkItem+0x1c6
1cdef45c 72e52591 8843c914 72e5245b 00000000 clr!ThreadpoolMgr::ExecuteWorkRequest+0x42
1cdef4c4 72e5b4ad 00000000 00000000 776620c0 clr!ThreadpoolMgr::WorkerThreadStart+0x353
1cdef85c 751933ca 1b89d348 1cdef8a8 77599ed2 clr!Thread::intermediateThreadProc+0x4d
1cdef868 77599ed2 1b89d348 4e01fdde 00000000 kernel32!BaseThreadInitThunk+0xe
1cdef8a8 77599ea5 72e5b464 1b89d348 ffffffff ntdll!__RtlUserThreadStart+0x70
1cdef8c0 00000000 72e5b464 1b89d348 00000000 ntdll!_RtlUserThreadStart+0x1b


FOLLOWUP_IP: 
clr!Thread::DoADCallBack+2d3
72fae48a 8b4508          mov     eax,dword ptr [ebp+8]

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  clr!Thread::DoADCallBack+2d3

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: clr

IMAGE_NAME:  clr.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  52310b2d

STACK_COMMAND:  ~34s; .ecxr ; kb

FAILURE_BUCKET_ID:  WRONG_SYMBOLS_e0434352_clr.dll!Thread::DoADCallBack

BUCKET_ID:  APPLICATION_FAULT_WRONG_SYMBOLS_CLR_EXCEPTION_clr!Thread::DoADCallBack+2d3

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:wrong_symbols_e0434352_clr.dll!thread::doadcallback

FAILURE_ID_HASH:  {15ee992e-553a-06bb-20c5-a254780b9452}

Followup: MachineOwner

Anybody any ideas???

Thanks a lot!

R P
  • 1
  • 1
  • Try capturing the dump using a 32bit debugger. I'd recommend setting up [ProcDump](https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx) or [DebugDiag](http://www.microsoft.com/en-us/download/details.aspx?id=42933) to capture a dump on unhandled exceptions so you can get a 32bit dump file. – Sean Cline Sep 01 '15 at 13:53
  • possible duplicate of [How do I take a good crash dump for .NET?](http://stackoverflow.com/questions/24874027/how-do-i-take-a-good-crash-dump-for-net) – Thomas Weller Sep 01 '15 at 14:10
  • WinDbg has no limit in the size of the dump. You can even open 64 bit dumps with 32 bit WinDbg. However, you should open the dump in WinDbg64 and try `.effmach x86` to make it work. Some commands will not work. Unfortunately there's no way of converting a 64 bit dump into a 32 bit one, so you'd need to create a "better" one by reproducing the issue. – Thomas Weller Sep 01 '15 at 14:17
  • Ok getting somewhere, although don't think the symbols are loading properly from MS. Edited the original post with output above – R P Sep 01 '15 at 16:16
  • It is a .NET exception like I already expected, since it was an IIS dump. Unfortunately Microsoft does not provide a cross-bitness version of MSCorDacWks.dll, which is needed to fully analyze the crash on .NET side. See [How to set up symbols](http://stackoverflow.com/a/30019890/480982) to see if you did everything right so far. – Thomas Weller Sep 01 '15 at 21:03

0 Answers0