WinDbg does not show full stack trace for some minidump-files - c++

I'm trying to set up a crashdump system to better be able to debug errors that I can't replicate easily on my own system
Here's my test program (Compiled with Release x64 Configuration with Visual Studio 2017):
#include "pch.h"
#include <iostream>
#include <Windows.h>
#include <DbgHelp.h>
#pragma comment(lib,"Dbghelp.lib")
BOOL MiniDumpWriteDump(
HANDLE hProcess,
DWORD ProcessId,
HANDLE hFile,
MINIDUMP_TYPE DumpType,
PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);
LONG CreateMiniDump( struct _EXCEPTION_POINTERS *pExceptionInfo )//EXCEPTION_POINTERS* pep )
{
// Open the file
HANDLE hFile = CreateFile( "MiniDump.dmp", GENERIC_READ | GENERIC_WRITE,
0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
if( ( hFile != NULL ) && ( hFile != INVALID_HANDLE_VALUE ) )
{
// Create the minidump
MINIDUMP_EXCEPTION_INFORMATION mdei;
mdei.ThreadId = GetCurrentThreadId();
mdei.ExceptionPointers = pExceptionInfo;
mdei.ClientPointers = FALSE;
MINIDUMP_TYPE mdt = MiniDumpNormal;
BOOL rv = MiniDumpWriteDump( GetCurrentProcess(), GetCurrentProcessId(),
hFile, mdt, (pExceptionInfo != 0) ? &mdei : 0, 0, 0 );
if( !rv )
std::cout<<"MiniDumpWriteDump failed. Error: "<<GetLastError()<<std::endl;
else
std::cout<<"Minidump created."<<std::endl;
// Close the file
CloseHandle( hFile );
}
else
{
std::cout<<"CreateFile failed. Error: "<<GetLastError()<<std::endl;
}
return EXCEPTION_EXECUTE_HANDLER;
}
static void ftest3()
{
throw std::runtime_error("Error");
}
static void ftest2()
{
ftest3();
}
static void ftest1()
{
ftest2();
}
int main()
{
SetUnhandledExceptionFilter(&CreateMiniDump);
ftest1();
}
(Source: http://www.debuginfo.com/articles/effminidumps2.html)
If I run it on my primary system (on which I compiled the program), and then load the .dmp-file in Visual Studio or WinDbg, the full stack trace is displayed correctly and I can see where the error has occurred:
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 000000fd`3bbbf6f0 00007ff8`a72142cd KERNELBASE!RaiseException+0x68
01 000000fd`3bbbf7d0 00007ff7`7b4f130f VCRUNTIME140!_CxxThrowException+0xad [f:\dd\vctools\crt\vcruntime\src\eh\throw.cpp # 133]
02 000000fd`3bbbf840 00007ff7`7b4f1319 test_minidump!ftest3+0x1f [c:\users\florian\documents\projects\test_minidump\test_minidump\test_minidump.cpp # 63]
03 000000fd`3bbbf890 00007ff7`7b4f1329 test_minidump!ftest2+0x9 [c:\users\florian\documents\projects\test_minidump\test_minidump\test_minidump.cpp # 68]
04 000000fd`3bbbf8c0 00007ff7`7b4f1346 test_minidump!ftest1+0x9 [c:\users\florian\documents\projects\test_minidump\test_minidump\test_minidump.cpp # 73]
05 000000fd`3bbbf8f0 00007ff7`7b4f1838 test_minidump!main+0x16 [c:\users\florian\documents\projects\test_minidump\test_minidump\test_minidump.cpp # 79]
06 (Inline Function) --------`-------- test_minidump!invoke_main+0x22 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 78]
07 000000fd`3bbbf920 00007ff8`b45d3034 test_minidump!__scrt_common_main_seh+0x10c [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 288]
08 000000fd`3bbbf960 00007ff8`b71a1461 kernel32!BaseThreadInitThunk+0x14
09 000000fd`3bbbf990 00000000`00000000 ntdll!RtlUserThreadStart+0x21
However, if I run the program on a different system, and then try to analyze the dump on my own system, all I get is this:
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 00000021`ccbef870 00007ffe`8cfd4722 KERNELBASE!RaiseException+0x68
01 00000021`ccbef950 00000021`ccbef9f0 VCRUNTIME140!_CxxThrowException+0xc2 [f:\dd\vctools\crt\vcruntime\src\eh\throw.cpp # 136]
02 00000021`ccbef958 00007ffe`00000000 0x00000021`ccbef9f0
03 00000021`ccbef960 000001ee`2e25ff30 0x00007ffe`00000000
04 00000021`ccbef968 00000000`00000000 0x000001ee`2e25ff30
Which isn't exactly helpful. I've loaded the dump-file in WinDbg and then used the following commands:
.symfix
.sympath+ C:\Users\Florian\Documents\Projects\test_minidump\x64\Release
.srcpath C:\Users\Florian\Documents\Projects\test_minidump\test_minidump
!analyze -v
.ecxr
k
Here's the full output from WinDbg:
Microsoft (R) Windows Debugger Version 10.0.17134.12 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\Florian\Desktop\tmp\MiniDump.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Version 17134 MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
17134.1.amd64fre.rs4_release.180410-1804
Machine Name:
Debug session time: Sun Sep 23 11:56:45.000 2018 (UTC + 2:00)
System Uptime: not available
Process Uptime: not available
..............
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(169c.1b78): C++ EH exception - code e06d7363 (first/second chance not available)
ntdll!NtGetContextThread+0x14:
00007ffe`9abfbc44 c3 ret
0:000> .symfix
0:000> .sympath+ C:\Users\Florian\Documents\Projects\test_minidump\x64\Release
Symbol search path is: srv*;C:\Users\Florian\Documents\Projects\test_minidump\x64\Release
Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols;c:\users\florian\documents\projects\test_minidump\x64\release
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
OK C:\Users\Florian\Documents\Projects\test_minidump\x64\Release
0:000> .srcpath C:\Users\Florian\Documents\Projects\test_minidump\test_minidump
Source search path is: C:\Users\Florian\Documents\Projects\test_minidump\test_minidump
************* Path validation summary **************
Response Time (ms) Location
OK C:\Users\Florian\Documents\Projects\test_minidump\test_minidump
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
Timeline: !analyze.Start
Name: <blank>
Time: 2018-09-24T10:08:32.944Z
Diff: 87107944 mSec
Timeline: Dump.Current
Name: <blank>
Time: 2018-09-23T09:56:45.0Z
Diff: 0 mSec
DUMP_CLASS: 2
DUMP_QUALIFIER: 400
CONTEXT: (.ecxr)
rax=0000000000000000 rbx=00007ffe973da570 rcx=0000000000000000
rdx=0000000000000030 rsi=00007ff798203cd0 rdi=000001ee2e25c750
rip=00007ffe97bba388 rsp=00000021ccbef870 rbp=00000021ccbef9b0
r8=0000000000000000 r9=0000000000000000 r10=000001ee2e0f0000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=00000021ccbef9f0 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206
KERNELBASE!RaiseException+0x68:
00007ffe`97bba388 488b8c24c0000000 mov rcx,qword ptr [rsp+0C0h] ss:00000021`ccbef930=000052660787015b
Resetting default scope
FAULTING_IP:
KERNELBASE!RaiseException+68
00007ffe`97bba388 488b8c24c0000000 mov rcx,qword ptr [rsp+0C0h]
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ffe97bba388 (KERNELBASE!RaiseException+0x0000000000000068)
ExceptionCode: e06d7363 (C++ EH exception)
ExceptionFlags: 00000001
NumberParameters: 4
Parameter[0]: 0000000019930520
Parameter[1]: 00000021ccbef9f0
Parameter[2]: 00007ff798203cd0
Parameter[3]: 00007ff798200000
BUGCHECK_STR: CPP_EXCEPTION
DEFAULT_BUCKET_ID: CPP_EXCEPTION
PROCESS_NAME: test_minidump.exe
ERROR_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>
EXCEPTION_CODE_STR: e06d7363
EXCEPTION_PARAMETER1: 0000000019930520
EXCEPTION_PARAMETER2: 00000021ccbef9f0
EXCEPTION_PARAMETER3: 00007ff798203cd0
EXCEPTION_PARAMETER4: 7ff798200000
WATSON_BKT_PROCSTAMP: 5ba8b478
WATSON_BKT_MODULE: KERNELBASE.dll
WATSON_BKT_MODSTAMP: b0bb231d
WATSON_BKT_MODOFFSET: 3a388
WATSON_BKT_MODVER: 6.2.17134.165
MODULE_VER_PRODUCT: Microsoft® Windows® Operating System
BUILD_VERSION_STRING: 17134.1.amd64fre.rs4_release.180410-1804
MODLIST_WITH_TSCHKSUM_HASH: 636d437315fdc5447e163e64094b1f6a26123a83
MODLIST_SHA1_HASH: 74dec0c40d229cd1e109927f1f5e794fa53165ac
DUMP_FLAGS: 0
DUMP_TYPE: 2
ANALYSIS_SESSION_HOST: DESKTOP-VFOALG8
ANALYSIS_SESSION_TIME: 09-24-2018 12:08:32.0944
ANALYSIS_VERSION: 10.0.17134.12 amd64fre
THREAD_ATTRIBUTES:
PROBLEM_CLASSES:
ID: [0n317]
Type: [#APPLICATION_FAULT_STRING]
Class: Primary
Scope: DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
BUCKET_ID
Name: Omit
Data: Add
String: [CPP_EXCEPTION]
PID: [Unspecified]
TID: [Unspecified]
Frame: [0]
PRIMARY_PROBLEM_CLASS: CPP_EXCEPTION
LAST_CONTROL_TRANSFER: from 00007ffe8cfd4722 to 00007ffe97bba388
STACK_TEXT:
00000021`ccbef870 00007ffe`8cfd4722 : 00000021`ccbef9f0 00007ffe`00000000 000001ee`2e25ff30 00000000`00000000 : KERNELBASE!RaiseException+0x68
00000021`ccbef950 00000021`ccbef9f0 : 00007ffe`00000000 000001ee`2e25ff30 00000000`00000000 00000001`e06d7363 : VCRUNTIME140!_CxxThrowException+0xc2
00000021`ccbef958 00007ffe`00000000 : 000001ee`2e25ff30 00000000`00000000 00000001`e06d7363 00000000`00000000 : 0x00000021`ccbef9f0
00000021`ccbef960 000001ee`2e25ff30 : 00000000`00000000 00000001`e06d7363 00000000`00000000 00000000`00000000 : 0x00007ffe`00000000
00000021`ccbef968 00000000`00000000 : 00000001`e06d7363 00000000`00000000 00000000`00000000 00000000`00000004 : 0x000001ee`2e25ff30
THREAD_SHA1_HASH_MOD_FUNC: 74c55fd19222dcb5ad415427110811b213f4c078
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 7592380e0f749a34b2d654a7c3b829a033ee79fa
THREAD_SHA1_HASH_MOD: ad69e1f2190edbb9a7df71b4b6403437528645f2
FOLLOWUP_IP:
KERNELBASE!RaiseException+68
00007ffe`97bba388 488b8c24c0000000 mov rcx,qword ptr [rsp+0C0h]
FAULT_INSTR_CODE: 248c8b48
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: KERNELBASE!RaiseException+68
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: KERNELBASE
IMAGE_NAME: KERNELBASE.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 0
STACK_COMMAND: ~0s ; .ecxr ; kb
BUCKET_ID: CPP_EXCEPTION_KERNELBASE!RaiseException+68
FAILURE_EXCEPTION_CODE: e06d7363
FAILURE_IMAGE_NAME: KERNELBASE.dll
BUCKET_ID_IMAGE_STR: KERNELBASE.dll
FAILURE_MODULE_NAME: KERNELBASE
BUCKET_ID_MODULE_STR: KERNELBASE
FAILURE_FUNCTION_NAME: RaiseException
BUCKET_ID_FUNCTION_STR: RaiseException
BUCKET_ID_OFFSET: 68
BUCKET_ID_MODTIMEDATESTAMP: 0
BUCKET_ID_MODCHECKSUM: 27e598
BUCKET_ID_MODVER_STR: 6.2.17134.165
BUCKET_ID_PREFIX_STR: CPP_EXCEPTION_
FAILURE_PROBLEM_CLASS: CPP_EXCEPTION
FAILURE_SYMBOL_NAME: KERNELBASE.dll!RaiseException
FAILURE_BUCKET_ID: CPP_EXCEPTION_e06d7363_KERNELBASE.dll!RaiseException
TARGET_TIME: 2018-09-23T09:56:45.000Z
OSBUILD: 17134
OSSERVICEPACK: 1
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 256
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2020-08-28 06:38:41
BUILDDATESTAMP_STR: 180410-1804
BUILDLAB_STR: rs4_release
BUILDOSVER_STR: 10.0.17134.1.amd64fre.rs4_release.180410-1804
ANALYSIS_SESSION_ELAPSED_TIME: a63
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:cpp_exception_e06d7363_kernelbase.dll!raiseexception
FAILURE_ID_HASH: {1253aecc-520d-655b-58e3-5eb61e209188}
Followup: MachineOwner
---------
0:000> .ecxr
rax=0000000000000000 rbx=00007ffe973da570 rcx=0000000000000000
rdx=0000000000000030 rsi=00007ff798203cd0 rdi=000001ee2e25c750
rip=00007ffe97bba388 rsp=00000021ccbef870 rbp=00000021ccbef9b0
r8=0000000000000000 r9=0000000000000000 r10=000001ee2e0f0000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=00000021ccbef9f0 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206
KERNELBASE!RaiseException+0x68:
00007ffe`97bba388 488b8c24c0000000 mov rcx,qword ptr [rsp+0C0h] ss:00000021`ccbef930=000052660787015b
0:000> k
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 00000021`ccbef870 00007ffe`8cfd4722 KERNELBASE!RaiseException+0x68
01 00000021`ccbef950 00000021`ccbef9f0 VCRUNTIME140!_CxxThrowException+0xc2 [f:\dd\vctools\crt\vcruntime\src\eh\throw.cpp # 136]
02 00000021`ccbef958 00007ffe`00000000 0x00000021`ccbef9f0
03 00000021`ccbef960 000001ee`2e25ff30 0x00007ffe`00000000
04 00000021`ccbef968 00000000`00000000 0x000001ee`2e25ff30
There are no warnings or errors from what I can tell, so why am I not getting the full stack trace information?

VCRUNTIME140!_CxxThrowException+0xad [f:\dd\vctools\crt\vcruntime\src\eh\throw.cpp # 133]
versus
VCRUNTIME140!_CxxThrowException+0xc2 [f:\dd\vctools\crt\vcruntime\src\eh\throw.cpp # 136]
is a bit worrying. It suggests that the minor version of the MSVC runtime doesn't match between the two machines (because otherwise, why would they invoke RaiseException from different source lines). If your WinDbg session doesn't have symbols for the remote machine's VCRUNTIME140 -- or, worse yet, if it's using the wrong PDB for it -- backtracing is going to become problematic at that point. WinDbg should automatically download and load symbols for whichever version is referenced from the minidump, but I suspect this isn't happening properly.
Use lm v to show the module listing for the minidump, and pay close attention to the checksum information. I suspect you'll see a different checksum for vcruntime140.dll between the two machines. If you do, you'll need to figure out why you're not getting the right symbols for the dll.

Thanks to the tips by users Sneftel and Sean Cline, I found the solution. Running the command !itoldyouso vcruntime140 gives me the following output:
sig MISMATCH: vcruntime140.amd64.pdb and VCRUNTIME140.dll
The problem was that my system which I use for debugging runs on an AMD CPU, while the system that generated the crashdump runs on an intel CPU. For some reason the vcruntime140.dll is system-specific and differs between the two. (Also, on AMD systems the pdb is called "vcruntime140.amd64.pdb", on intel it's "vcruntime140.i386.pdb".)
I've copied the vcruntime140.dll, vcruntime140.i386.pdb and msvcp140.dll from my intel system and added them to the symbol path for WinDbg. Then I ran the same commands as before, and now it outputs the full stacktrace.
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 00000021`ccbef870 00007ffe`8cfd4722 KERNELBASE!RaiseException+0x68
01 00000021`ccbef950 00007ff7`9820130f VCRUNTIME140!_CxxThrowException+0xc2 [f:\dd\vctools\crt\vcruntime\src\eh\throw.cpp # 136]
02 00000021`ccbef9d0 00007ff7`98201319 test_minidump!ftest3+0x1f [c:\users\florian\documents\projects\test_minidump\test_minidump\test_minidump.cpp # 63]
03 00000021`ccbefa20 00007ff7`98201329 test_minidump!ftest2+0x9 [c:\users\florian\documents\projects\test_minidump\test_minidump\test_minidump.cpp # 68]
04 00000021`ccbefa50 00007ff7`98201346 test_minidump!ftest1+0x9 [c:\users\florian\documents\projects\test_minidump\test_minidump\test_minidump.cpp # 73]
05 00000021`ccbefa80 00007ff7`98201838 test_minidump!main+0x16 [c:\users\florian\documents\projects\test_minidump\test_minidump\test_minidump.cpp # 79]
06 (Inline Function) --------`-------- test_minidump!invoke_main+0x22 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 78]
07 00000021`ccbefab0 00007ffe`98983034 test_minidump!__scrt_common_main_seh+0x10c [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 288]
08 00000021`ccbefaf0 00007ffe`9abd1461 kernel32!BaseThreadInitThunk+0x14
09 00000021`ccbefb20 00000000`00000000 ntdll!RtlUserThreadStart+0x21

Related

using windbg to troubleshoot unzip throws c++ runtime error abnormal program termination

I'm new to using windbg. I'm trying to determine root cause of why an application throws abnormal program termination. It's a updater app that downloads password protected zip files and unpacks them to make an update.
Typically, these errors are caused a network device blocking the download. But I want to know for sure if its the download or the unzip causing this. I created a dump file using Windows Task Manager when the error was shown on the screen.
I've gotten as far as the output below in windbg. I'm not sure where to go from here. I think the error happened on thread 2 because it has Unhandled Exception Filter. I tried dumping out the dwords for the return addresses but I'm not sure what that output means; just a bunch of bytes to me.
Any advice on how to continue investigating this would be appreciated.
Symbol search path is: srv*https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8.1 Version 9600 MP (4 procs) Free x64
Product: Server, suite: TerminalServer DataCenter
Edition build lab: 6.3.9600.18217 (winblue_ltsb.160124-0053)
Machine Name:
Debug session time: Wed Jan 19 13:52:46.000 2022 (UTC - 8:00)
System Uptime: 5 days 1:09:46.245
Process Uptime: 0 days 0:01:10.000
................................................................
......
For analysis of this file, run !analyze -v
wow64win!NtUserGetMessage+0xa:
00000000`77775a2a c3 ret
0:000:x86> !pcr
Unable to read processor block array
Cannot get PCR address
0:000:x86> ~*k
. 0 Id: 3c2c.3e28 Suspend: 0 Teb: 7ffdb000 Unfrozen
# ChildEBP RetAddr
00 0018f970 77225dac user32!NtUserGetMessage+0xc
01 0018f998 0046e8b6 user32!GetMessageA+0x4c
WARNING: Stack unwind information not available. Following frames may be wrong.
02 004a4ed0 00000000 UPDATER+0x6e8b6
1 Id: 3c2c.4bc4 Suspend: 0 Teb: 7ffd8000 Unfrozen
# ChildEBP RetAddr
00 0280ff3c 742dc150 ntdll_777d0000!NtRemoveIoCompletion+0xc
01 0280ff80 77037c04 mswsock!SockAsyncThread+0x7d
02 0280ff94 7782ad8f kernel32!BaseThreadInitThunk+0x24
03 0280ffdc 7782ad5a ntdll_777d0000!__RtlUserThreadStart+0x2f
04 0280ffec 00000000 ntdll_777d0000!_RtlUserThreadStart+0x1b
2 Id: 3c2c.3dd0 Suspend: 0 Teb: 7ffd5000 Unfrozen
# ChildEBP RetAddr
00 03c9ea90 77224371 user32!NtUserWaitMessage+0xc
01 03c9ead8 77214fcd user32!DialogBox2+0x13f
02 03c9eb08 7721f907 user32!InternalDialogBox+0x107
03 03c9ebd4 7721f06d user32!SoftModalMessageBox+0xe2c
04 03c9ed38 7726786b user32!MessageBoxWorker+0x293
05 03c9edb8 772677cb user32!MessageBoxTimeoutW+0x6b
06 03c9edec 7726760b user32!MessageBoxTimeoutA+0x7b
07 03c9ee0c 772675d8 user32!MessageBoxExA+0x1b
08 03c9ee28 00464854 user32!MessageBoxA+0x18
WARNING: Stack unwind information not available. Following frames may be wrong.
09 03c9f028 0046347c UPDATER+0x64854
0a 03c9f060 767ef445 UPDATER+0x6347c
0b 03c9f0e8 00462b1c KERNELBASE!UnhandledExceptionFilter+0x165
0c 03c9f100 0045a33d UPDATER+0x62b1c
0d 03c9ff80 77037c04 UPDATER+0x5a33d
0e 03c9ff94 7782ad8f kernel32!BaseThreadInitThunk+0x24
0f 03c9ffdc 7782ad5a ntdll_777d0000!__RtlUserThreadStart+0x2f
10 03c9ffec 00000000 ntdll_777d0000!_RtlUserThreadStart+0x1b
0:000:x86> dc 00462b1c
00462b1c c3c95b5e 0824548b 3ab40d8b 8b56004a ^[...T$....:J.V.
00462b2c 39082474 c28b5732 3c8d1174 ba3c8d49 t$.92W..t.."u.F.. dc 0045a33d
0045a33d 8bc35959 75ffe865 e5bee8e0 d0a1ffff YY..e..u........
0045a34d 85004a0b ff0274c0 f7e856d0 8b000013 .J...t...V......
0045a35d 75f685f0 e8106a08 fffff1ae 4ae85659 ...u.j......YV.J
0045a36d 59000014 082474ff 113c15ff c35e0048 ...Y.t$... ~2 s
user32!NtUserWaitMessage+0xc:
7720bfbc c3 ret
0:002:x86> !teb
Wow64 TEB32 at 7ffd7000
ExceptionList: 03c9f04c
StackBase: 03ca0000
StackLimit: 03c9c000
SubSystemTib: 00000000
FiberData: 00001e00
ArbitraryUserPointer: 00000000
Self: 7ffd7000
EnvironmentPointer: 00000000
ClientId: 00003c2c . 00003dd0
RpcHandle: 00000000
Tls Storage: 00332810
PEB Address: 7ffde000
LastErrorValue: 0
LastStatusValue: c0000034
Count Owned Locks: 0
HardErrorMode: 0
Wow64 TEB at 7ffd5000
ExceptionList: 7ffd7000
StackBase: 023ffd30
StackLimit: 023f8000
SubSystemTib: 00000000
FiberData: 00001e00
ArbitraryUserPointer: 00000000
Self: 7ffd5000
EnvironmentPointer: 00000000
ClientId: 00003c2c . 00003dd0
RpcHandle: 00000000
Tls Storage: 00000000
PEB Address: 7ffdf000
LastErrorValue: 0
LastStatusValue: 0
Count Owned Locks: 0
HardErrorMode: 0
0:002:x86> dc 03c9f04c
03c9f04c 03c9f0d8 0045ba3c 00489530 ffffffff .... dc 7ffd7000
7ffd7000 03c9f04c 03ca0000 03c9c000 00000000 L...............
7ffd7010 00001e00 00000000 7ffd7000 00000000 .........p......
7ffd7020 00003c2c 00003dd0 00000000 00332810 ,

Access violation using different c++ runtime build VS 2017

I got an c0000005 memory exception when my program use a newer version of c++ runtime, specifically of msvcp140.dll :
14.16.27012.6 the program works
14.24.28127.4 the program crashes.
My application uses signalrclient library for connecting to our web service. When there’s a problem with the connection, the program crashes with an access violation.
I got the stack from a dump:
00 0b7ff34c 0b7ff370 BC32RECV!__ExceptionPtr::_RethrowException+0x82 [d:\agent\_work\3\s\src\vctools\crt\crtw32\eh\excptptr.cpp # 541]
WARNING: Frame IP not in any known module. Following frames may be wrong.
01 0b7ff350 052b1466 0xb7ff370
02 0b7ff358 052b1561 BC32RECV!std::exception_ptr::_RethrowException+0x6 [c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\include\exception # 282]
03 0b7ff370 052b395b BC32RECV!std::rethrow_exception+0x31 [c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\include\exception # 358]
04 0b7ff388 052b3e8f BC32RECV!Concurrency::details::_ExceptionHolder::_RethrowUserException+0x2b [c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\include\ppltasks.h # 789]
05 0b7ff3d8 052b9d09 BC32RECV!Concurrency::details::_Task_impl_base::_Wait+0x22f [c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\include\ppltasks.h # 1613]
06 (Inline) -------- BC32RECV!Concurrency::task<unsigned char>::wait+0xf [c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\include\ppltasks.h # 3297]
07 (Inline) -------- BC32RECV!Concurrency::task<void>::wait+0xf [c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\include\ppltasks.h # 4223]
08 0b7ffa60 052c75e1 BC32RECV!try_connection+0x479 [c:\my .net projects\builder\main\utility\bc32recv\bc32recv.cpp # 578]
The code of my function is :
try {
client->connection.start().wait(); -> access vio
connection_success = true;
}
catch (std::exception& ex)
{
...
}
It seems it had a different std::exception_ptr, changing version from 14.16.27012.6 to 14.24.28127.4 of msvcp140.dll.
I assumed compatibility was maintained in this case when only the build / minor version changes.
The exception info from the dump is:
0:014> .exr -1
ExceptionAddress: 052c7d2e (BC32RECV!__ExceptionPtr::_RethrowException+0x00000082)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: b0688e75
Attempt to read from address b0688e75
There's a attempt of reading b0688e75 address.
The first frame of the stack reports:
frame 0n0;dv /t /v
00 0b7ff34c 0b7ff370 BC32RECV!__ExceptionPtr::_RethrowException+0x82 [d:\agent\_work\3\s\src\vctools\crt\crtw32\eh\excptptr.cpp # 541]
#ebx              class __ExceptionPtr * this = 0x0a09b2bc
0b7ff2f8          struct _EXCEPTION_RECORD ThisException = struct _EXCEPTION_RECORD
#eax              struct _s_ThrowInfo * pThrow = 0xb0688e69
<unavailable>     struct _s_CatchableType * pType = <value unavailable>
<unavailable>     void * pExceptionBuffer = <value unavailable>
I dont know how to "read" theese infos. What it seems near to the address VAM is
#eax              struct _s_ThrowInfo * pThrow = 0xb0688e69
and it seems wrong:
((BC32RECV!_s_ThrowInfo *)0xffffffffb0688e69) : 0xffffffffb0688e69 [Type: _s_ThrowInfo *]
[+0x000] attributes : Unable to read memory at Address 0xffffffffb0688e69
[+0x004] pmfnUnwind : Unable to read memory at Address 0xffffffffb0688e6d
[+0x008] pForwardCompat : Unable to read memory at Address 0xffffffffb0688e71
[+0x00c] pCatchableTypeArray : Unable to read memory at Address 0xffffffffb0688e75

Visual Studio 2015 cross platform c++ hangs after build in vslog!VSResponsiveness::Detours

I have a Visual Studio 2015 Professional Update 2 crossplatform c++ solution with shared, android and ios projects. It looks like the projects build successfully, but then Visual Studio hangs. I am unable to cancel the build or restart visual studio. I have to kill the devenv process, then open it again.
In windbg, I see the hanging thread as this:
0:000> kb
ChildEBP RetAddr Args to Child
0018f228 754da4fa 00000001 0018f3fc 00000001 ntdll!NtWaitForMultipleObjects+0xc
0018f3bc 7447c47b 00000001 0018f3fc 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x10a
0018f424 6cb610f7 00000000 00000000 ffffffff user32!MsgWaitForMultipleObjectsEx+0x17b
0018f448 5ec48c36 00000000 00000000 ffffffff vslog!VSResponsiveness::Detours::DetourMsgWaitForMultipleObjectsEx+0x45
0018f490 5eb072d5 7c443f4b 00000000 00d96a00 msenv!CMsoCMHandler::EnvironmentMsgLoop+0x15b
0018f4b8 5eb0722b 00000001 ffffffff 7c443f0b msenv!CMsoCMHandler::FPushMessageLoop+0x105
0018f4f8 5eb0716f 00000001 0917f998 00001684 msenv!SCM::FPushMessageLoop+0xb9
0018f518 5eb07136 00d96a04 050fe9c8 ffffffff msenv!SCM_MsoCompMgr::FPushMessageLoop+0x2a
0018f544 5eb07086 ffffffff 7c443e2b 00000000 msenv!CMsoComponent::PushMsgLoop+0x2e
0018f5d8 5ebf23b3 7c443df3 00000000 5eac0000 msenv!VStudioMainLogged+0x5bd
0018f600 2f5afed2 00ce3b20 0c66fc01 00000000 msenv!VStudioMain+0x7c
0018f640 2f5afaaa 0c66f359 74b9aba0 2f5bfa50 devenv!util_CallVsMain+0xde
0018f918 2f5c36e3 00000000 2f5fa570 003f9000 devenv!CDevEnvAppId::Run+0xbb5
0018f944 2f5c3803 2f5a0000 00000000 00cd50c5 devenv!WinMain+0xbd
0018f990 74b938f4 003f9000 74b938d0 57fa7e12 devenv!__scrt_common_main_seh+0xfd
0018f9a4 77455de3 003f9000 54766e72 00000000 kernel32!BaseThreadInitThunk+0x24
0018f9ec 77455dae ffffffff 7747b7dd 00000000 ntdll!__RtlUserThreadStart+0x2f
0018f9fc 00000000 2f5c0fe2 003f9000 00000000 ntdll!_RtlUserThreadStart+0x1b
Here is the !analyze output:
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** WARNING: Unable to verify checksum for PresentationCore.ni.dll
*** WARNING: Unable to verify checksum for System.ni.dll
*** WARNING: Unable to verify checksum for WindowsBase.ni.dll
*** WARNING: Unable to verify checksum for Microsoft.VisualStudio.Shell.14.0.ni.dll
*** WARNING: Unable to verify checksum for System.Runtime.Remoting.ni.dll
*** WARNING: Unable to verify checksum for Microsoft.Build.ni.dll
*** WARNING: Unable to verify checksum for Microsoft.CodeAnalysis.Features.ni.dll
*** WARNING: Unable to verify checksum for Microsoft.CodeAnalysis.Workspaces.ni.dll
*** WARNING: Unable to verify checksum for Microsoft.VisualStudio.JSLS.ni.dll
*** The OS name list needs to be updated! Unknown Windows version: 10.0 ***
FAULTING_IP:
+0
00000000 ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000007 (Wake debugger)
ExceptionFlags: 00000000
NumberParameters: 0
CONTEXT: 00000000 -- (.cxr 0x0;r)
eax=000000b8 ebx=00000001 ecx=00000000 edx=00000000 esi=00000001 edi=00000001
eip=7746718c esp=0018f22c ebp=0018f3bc iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
ntdll!NtWaitForMultipleObjects+0xc:
7746718c c21400 ret 14h
BUGCHECK_STR: 80000007
DEFAULT_BUCKET_ID: APPLICATION_HANG
PROCESS_NAME: devenv.exe
ERROR_CODE: (NTSTATUS) 0x80000007 - {Kernel Debugger Awakened} the system debugger was awakened by an interrupt.
EXCEPTION_CODE: (HRESULT) 0x80000007 (2147483655) - Operation aborted
APP: devenv.exe
ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x9ac (0)
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
ChildEBP RetAddr Caller, Callee
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- --------------------------
0 1684.9ac Handle
WAIT_CHAIN_COMMAND: ~0s;k;;
BLOCKING_THREAD: 000009ac
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG
LAST_CONTROL_TRANSFER: from 754da4fa to 7746718c
FAULTING_THREAD: 00000000
STACK_TEXT:
0018f228 754da4fa 00000001 0018f3fc 00000001 ntdll!NtWaitForMultipleObjects+0xc
0018f3bc 7447c47b 00000001 0018f3fc 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x10a
0018f424 6cb610f7 00000000 00000000 ffffffff user32!MsgWaitForMultipleObjectsEx+0x17b
0018f448 5ec48c36 00000000 00000000 ffffffff vslog!VSResponsiveness::Detours::DetourMsgWaitForMultipleObjectsEx+0x45
0018f490 5eb072d5 7c443f4b 00000000 00d96a00 msenv!CMsoCMHandler::EnvironmentMsgLoop+0x15b
0018f4b8 5eb0722b 00000001 ffffffff 7c443f0b msenv!CMsoCMHandler::FPushMessageLoop+0x105
0018f4f8 5eb0716f 00000001 0917f998 00001684 msenv!SCM::FPushMessageLoop+0xb9
0018f518 5eb07136 00d96a04 050fe9c8 ffffffff msenv!SCM_MsoCompMgr::FPushMessageLoop+0x2a
0018f544 5eb07086 ffffffff 7c443e2b 00000000 msenv!CMsoComponent::PushMsgLoop+0x2e
0018f5d8 5ebf23b3 7c443df3 00000000 5eac0000 msenv!VStudioMainLogged+0x5bd
0018f600 2f5afed2 00ce3b20 0c66fc01 00000000 msenv!VStudioMain+0x7c
0018f640 2f5afaaa 0c66f359 74b9aba0 2f5bfa50 devenv!util_CallVsMain+0xde
0018f918 2f5c36e3 00000000 2f5fa570 003f9000 devenv!CDevEnvAppId::Run+0xbb5
0018f944 2f5c3803 2f5a0000 00000000 00cd50c5 devenv!WinMain+0xbd
0018f990 74b938f4 003f9000 74b938d0 57fa7e12 devenv!__scrt_common_main_seh+0xfd
0018f9a4 77455de3 003f9000 54766e72 00000000 kernel32!BaseThreadInitThunk+0x24
0018f9ec 77455dae ffffffff 7747b7dd 00000000 ntdll!__RtlUserThreadStart+0x2f
0018f9fc 00000000 2f5c0fe2 003f9000 00000000 ntdll!_RtlUserThreadStart+0x1b
FOLLOWUP_IP:
vslog!VSResponsiveness::Detours::DetourMsgWaitForMultipleObjectsEx+45
6cb610f7 8bf0 mov esi,eax
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: vslog!VSResponsiveness::Detours::DetourMsgWaitForMultipleObjectsEx+45
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: vslog
IMAGE_NAME: vslog.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 56f22f38
STACK_COMMAND: ~0s ; kb
BUCKET_ID: 80000007_vslog!VSResponsiveness::Detours::DetourMsgWaitForMultipleObjectsEx+45
FAILURE_BUCKET_ID: APPLICATION_HANG_80000007_vslog.dll!VSResponsiveness::Detours::DetourMsgWaitForMultipleObjectsEx
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:application_hang_80000007_vslog.dll!vsresponsiveness::detours::detourmsgwaitformultipleobjectsex
FAILURE_ID_HASH: {4beed356-b376-19fc-7fdd-b5445b7b3d57}
Followup: MachineOwner
---------
0:000> lmvm vslog
start end module name
6cb60000 6cbc2000 vslog (pdb symbols) C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\sym\VsLog.pdb\233146AA39DE4D9B96281A205CEFA40A2\VsLog.pdb
Loaded symbol image file: vslog.dll
Mapped memory image file: C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\sym\vslog.dll\56F22F3862000\vslog.dll
Image path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\vslog.dll
Image name: vslog.dll
Timestamp: Wed Mar 23 01:52:56 2016 (56F22F38)
CheckSum: 0006D56A
ImageSize: 00062000
File version: 14.0.25123.0
Product version: 14.0.25123.0
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Visual Studio® 2015
InternalName: VsLog.DLL
OriginalFilename: VsLog.DLL
ProductVersion: 14.0.25123.0
FileVersion: 14.0.25123.0 built by: D14REL
FileDescription: Visual Studio Logging
LegalCopyright: © Microsoft Corporation. All rights reserved.
No solution, but I'd like to add that I get the same hang on NTWaitformultipleObjects often in my VS2015 solution when removing items from a project.

CComPtrBase::~CComPtrBase is crashing while deallocating smart pointers

Recently we are seeing a significant increase in crashes related to COM at our client sites after they upgraded to Windows Server 2008R2. Initially we thought it might be due to COM reference counting issue, but after further investigation going through the code, we have ruled it out. Another angle that we are looking at is, is it possible that the COM library is getting un-initialized due to which this issue might be occurring? Again we have ruled it out after investigating going through the code. As of now we do not have any concrete answers.
Is there any known instances of COM crashes increasing after migrating to 64bit?
Below are the crash fingerprints. I have kept it concise for this post.
Crash 1:
0:000> kpn 2
# ChildEBP RetAddr
00 0033e9d8 662051d5 pvformscom!ATL::CComPtrBase::~CComPtrBase(void)+0x6 [c:\program files\microsoft visual studio 10.0\vc\atlmfc\include\atlcomcli.h # 162]
01 0033ea00 66210586 pvformscom!COrder::~COrder(void)+0xa6 [c:\2012.01_svc_dep\cpp\pvformscom\order.cpp # 149]
0:000> .frame 00
00 0033e9d8 662051d5 pvformscom!ATL::CComPtrBase::~CComPtrBase+0x6 [c:\program files\microsoft visual studio 10.0\vc\atlmfc\include\atlcomcli.h # 162]
0:000> dt this
Local var # ecx Type ATL::CComPtrBase*
{ 00000001 } +0x000 p : 0x00000001 ICalendar
Crash 2:
0:000> kpn 2
# ChildEBP RetAddr
00 0016e6d8 646052a9 pvformscom!ATL::CComPtrBase::~CComPtrBase(void)+0x6 [c:\program files\microsoft visual studio 10.0\vc\atlmfc\include\atlcomcli.h # 162]
01 0016e700 646106ae pvformscom!COrder::~COrder(void)+0x6f [c:\2012.01_svc_dep\cpp\pvformscom\order.cpp # 152]
0:000> .frame 00
00 0016e6d8 646052a9 pvformscom!ATL::CComPtrBase::~CComPtrBase+0x6 [c:\program files\microsoft visual studio 10.0\vc\atlmfc\include\atlcomcli.h # 162]
0:000> dt this
Local var # ecx Type ATL::CComPtrBase*
{ 00000001 } +0x000 p : 0x00000001 IImmunization
Crash 3:
0:000> kpn 2
# ChildEBP RetAddr
00 0032f008 6193f444 pvformscom!ATL::CComPtrBase::~CComPtrBase(void)+0x6 [c:\program files\microsoft visual studio 10.0\vc\atlmfc\include\atlcomcli.h # 162]
01 0032f038 6194d2a7 pvformscom!CClinicalEvent::~CClinicalEvent(void)+0x2df [c:\2012.01_svc_dep\cpp\pvformscom\clinicalevent.cpp # 170]
0:000> .frame 00
00 0032f008 6193f444 pvformscom!ATL::CComPtrBase::~CComPtrBase+0x6 [c:\program files\microsoft visual studio 10.0\vc\atlmfc\include\atlcomcli.h # 162]
0:000> dt this
Local var # ecx Type ATL::CComPtrBase*
{ 00000001 } +0x000 p : 0x00000001 IPVCollection
Any help is highly appreciated.
NOTE: We are using some smartpointers in our class as member varibale.
Thanks,
Sree
If you call Release() after ::CoUninitialize() that would be a reason for
this behavior.

Analyzing Crash in WinDbg

I have a .NET application that is crashing sometimes on exit. There's a bunch of COM and native stuff underneath the hood, too. It's a x86 application running on Windows 7 x64.
I've run through some WinDbg tutorials and I think I'm executing reasonable steps to get helpful information, but the stack trace itself isn't ringing any bells.
A few other tidbits:
I can reproduce this pretty consistently, say 75% of the time
If I clean up the threading (a lot of Thread.Abort()), it's reproducible maybe 20% of the time
Running the same procedure, I've seen a completely different stack trace than the one below, too
I'm using the 32-bit WinDbg. Here's the general process I've been using:
open the executable directly from WinDbg
set symbol path as: SRV*c:\sym*http://msdl.microsoft.com/download/symbols
type: .loadby sos clr
use the application, and get it to crash
Right after the crash, I get output:
(a38.1424): CLR exception - code e0434352 (first chance)
(a38.1424): CLR exception - code e0434352 (first chance)
(a38.1fd0): Unknown exception - code c000000d (first chance)
(a38.1fd0): Unknown exception - code c000000d (!!! second chance !!!)
eax=00000000 ebx=004dea1c ecx=7efdd000 edx=00000057 esi=7264d0c0 edi=07f2a248
eip=778715de esp=004dea08 ebp=004def50 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!ZwRaiseException+0x12:
778715de 83c404 add esp,4
If I type in ~ I only get one thread:
. 0 Id: a38.1fd0 Suspend: 1 Teb: 7efdd000 Unfrozen
Now, if I type in !analyze -v I get a big stack trace:
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
[ a bunch of symbol stuff loading here ]
FAULTING_IP:
ntdll!TpReleaseCleanupGroupMembers+276
778e4f52 a1b4009577 mov eax,dword ptr [ntdll!TppLogpRoutine (779500b4)]
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 778e4f52 (ntdll!TpReleaseCleanupGroupMembers+0x00000276)
ExceptionCode: c000000d
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 00001fd0
PROCESS_NAME: XXXXX.exe
ERROR_CODE: (NTSTATUS) 0xc000000d - An invalid parameter was passed to a service or function.
EXCEPTION_CODE: (NTSTATUS) 0xc000000d - An invalid parameter was passed to a service or function.
NTGLOBALFLAG: 70
APPLICATION_VERIFIER_FLAGS: 0
CONTEXT: 004dea6c -- (.cxr 0x4dea6c)
eax=004deee0 ebx=00000001 ecx=7efdd000 edx=00000057 esi=7264d0c0 edi=07f2a248
eip=778e4f52 esp=004deed0 ebp=004def50 iopl=0 nv up ei ng nz ac pe cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000297
ntdll!TpReleaseCleanupGroupMembers+0x276:
778e4f52 a1b4009577 mov eax,dword ptr [ntdll!TppLogpRoutine (779500b4)] ds:002b:779500b4=00000000
Resetting default scope
STACK_ADDR_RAW_STACK_SYMBOL: 4deb4c
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff]
LAST_CONTROL_TRANSFER: from 00000000 to 77883c04
DEFAULT_BUCKET_ID: STATUS_INVALID_PARAMETER
PRIMARY_PROBLEM_CLASS: STATUS_INVALID_PARAMETER
BUGCHECK_STR: APPLICATION_FAULT_STATUS_INVALID_PARAMETER
STACK_TEXT:
778e4f52 ntdll!TpReleaseCleanupGroupMembers+0x276
72630d69 AUDIOSES!DllCanUnloadNow+0x42
7565b5f4 ole32!CClassCache::CDllPathEntry::CanUnload_rl+0x3b
7565b771 ole32!CClassCache::FreeUnused+0x83
7565b68f ole32!CoFreeUnusedLibrariesEx+0x36
756a0ccb ole32!CoFreeUnusedLibraries+0x9
15e2f549 GxMetadata+0xf549
15e45e3d GxMetadata!DllCanUnloadNow+0x1686d
77889950 ntdll!LdrpCallInitRoutine+0x14
7789d6b2 ntdll!LdrShutdownProcess+0x1aa
7789d554 ntdll!RtlExitUserProcess+0x74
754279f4 KERNEL32!ExitProcessStub+0x12
720642f0 mscoreei!RuntimeDesc::ShutdownAllActiveRuntimes+0x29c
72064321 mscoreei!CLRRuntimeHostInternalImpl::ShutdownAllRuntimesThenExit+0x15
5ea18580 clr!EEPolicy::ExitProcessViaShim+0x66
5ea1862f clr!SafeExitProcess+0x122
5e9638a9 clr!DisableRuntime+0x120
5e963905 clr!EEPolicy::HandleExitProcess+0x5c
5e9b8af8 clr!_CorExeMainInternal+0xdd
5e9b3a30 clr!_CorExeMain+0x4e
720555ab mscoreei!_CorExeMain+0x38
72f67f16 MSCOREE!ShellShim__CorExeMain+0x99
72f64de3 MSCOREE!_CorExeMain_Exported+0x8
7542339a KERNEL32!BaseThreadInitThunk+0xe
77889ef2 ntdll!__RtlUserThreadStart+0x70
77889ec5 ntdll!_RtlUserThreadStart+0x1b
FOLLOWUP_IP:
AUDIOSES!DllCanUnloadNow+42
72630d69 ff3514d06472 push dword ptr [AUDIOSES!_AudioClientThreadpoolCleanupGroup (7264d014)]
EDIT 1: (additional info)
!clrstack
OS Thread Id: 0x1fd0 (0)
Child SP IP Call Site
GetFrameContext failed: 1
!threads
ThreadCount: 7
UnstartedThread: 0
BackgroundThread: 4
PendingThread: 0
DeadThread: 3
Hosted Runtime: no
PreEmptive GC Alloc Lock
ID OSID ThreadOBJ State GC Context Domain Count APT Exception
0 1 1fd0 005afe88 16220 Enabled 03051294:03051e6c 00578550 0 STA
XXXX 2 e5c 005801d0 b220 Enabled 0305a22c:0305be6c 00578550 0 MTA (Finalizer)
XXXX 3 00641258 19820 Enabled 00000000:00000000 00578550 0 Ukn
XXXX 4 06e4b800 819820 Enabled 00000000:00000000 00578550 0 Ukn
XXXX 5 18a0 081be620 200b220 Enabled 00000000:00000000 00578550 1 MTA
XXXX 8 081d5e18 819820 Enabled 00000000:00000000 00578550 0 Ukn
XXXX 7 158 07ed78d8 220 Enabled 00000000:00000000 00578550 0 Ukn
Looks like the ntdll!TpReleaseCleanupGroupMembers (the same as kernel32!CloseThreadpoolCleanupGroupMembers - you can look it up on msdn) function (from top of the fault stack) does not like to be called when the process is being shut down - it throws the exception you're seeing (invalid parameter) in this case.
From the presence of two more libs on the stack (audioses and gxmetadata) I'd guess some objects are destroyed/released way too late. audioses.dll seems to the Core Audio API library, not sure about the gxmetadata.dll - can you explain the use of these?