我有一个在IIS 7.5上运行的32位应用程序网站随机崩溃，并在WER目录下提供了一个hdmp文件。问题是转储文件大约3GB，32位Windbg工具无法读取，因为它会产生一个太大的错误。 Windbg的64位版本将读取它，但是当它运行任何命令时，它表示它无法运行，因为崩溃转储是针对32位应用程序。
有没有办法读取这个转储文件或以任何方式使其更小以便将来崩溃？ Windbg可以分析的32位崩溃转储是否存在大小限制，即2GB？我是一个系统管理员，而不是一个Web开发人员，所以这对我来说都是新的。
更新
得到了某种类型的输出！分析-v，虽然符号没有从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
任何人的想法???
非常感谢！