node-gyp resolving external library symbols on windows build - c++

I'm trying to build a node module on Windows 10 with MS VS 2015 and for some reason it's unable to resolve library symbols on node-gyp build. Here is my binding.gyp file:
{
'variables' : {
'include_path' : 'path/to/include',
'lib_path': '/path/to/lib',
},
'targets': [
{
// name and sources here
'include_dirs': [
'<(include_path)',
],
'libraries': [
'<(lib_path)',
],
},
],
}
For some reason, it's unable to resolve any symbols in the library. Here is a snippet of the output:
ProjectBuild.obj : error LNK2001: unresolved external symbol __imp__AiMsgSetLogFileFlags [\path\to\build\project_build.vcxproj]
ProjectBuild.obj : error LNK2001: unresolved external symbol __imp__AiRenderInterrupt [\path\to\build\project_build.vcxproj]
In addition, here is the disassembly of those symbols in the object file dump for that library:
Disassembly of section .text:
0000000000000000 <AiMsgSetLogFileFlags>:
0: ff 25 00 00 00 00 jmpq *0x0(%rip) # 6 <AiMsgSetLogFileFlags+0x6>
6: 90 nop
7: 90 nop
ai.dll: file format pei-x86-64
Disassembly of section .text:
0000000000000000 <AiRenderInterrupt>:
0: ff 25 00 00 00 00 jmpq *0x0(%rip) # 6 <AiRenderInterrupt+0x6>
6: 90 nop
7: 90 nop
ai.dll: file format pei-x86-64
I can confirm with 100% certainty that node-gyp is finding the library file. Does anyone know why it's having trouble linking the symbols in that file? For what it's worth, I'm able to build the module just fine in a linux environment with the exact same binding.gyp file.

You need to look into making sure that the symbols you want to export have this. https://msdn.microsoft.com/en-us/library/3y1sfaz2%28v=vs.140%29.aspx

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 ,

Python3 C++ Module - Exception - GIL not held

I have created a minimal reproduction of an issue I am having, trying to create a C++ based Python3 module. The build environment is CMake, Visual Studio Pro 2019, WinSDK 10.0.18362, Python 3.9.4. When executing:
python3 -c "import pymod"
I will get an exception in release mode with a NULL access. In debug Python, I get additional information.
My CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(pymod_minimal_repo_example)
find_package(Python3 COMPONENTS Interpreter Development)
add_library(pymod SHARED)
target_sources(pymod PRIVATE pymodmodule.cpp)
set_target_properties(pymod PROPERTIES SUFFIX ".pyd")
target_compile_options(pymod PRIVATE /Zi)
target_link_options(pymod PRIVATE /DEBUG:FULL)
target_link_libraries(pymod PRIVATE ${Python3_LIBRARIES})
target_include_directories(pymod PRIVATE ${Python3_INCLUDE_DIRS})
Following this python reference: https://docs.python.org/3.9/extending/extending.html#a-simple-example I created the following:
#define PY_SSIZE_T_CLEAN
#include <Python.h>
static struct PyModuleDef pymodmodule = {
PyModuleDef_HEAD_INIT, // m_base
"pymod", // m_name
NULL, // m_doc
-1, // m_size - submod not support must be static struct
NULL, // m_methods - no functions present
NULL, // m_slots - must be NULL
NULL, // m_traverse - not needed
NULL, // m_clear - not needed
NULL // m_free - not needed
};
PyMODINIT_FUNC PyInit_pymod(void) {
return PyModule_Create(&pymodmodule);
}
It is a functionally void module which does nothing, but should still run. Note that having m_methods defined, produces the same failure.
When the failure occurs, the following is output to the console:
E:\projects\pymod\build\Debug>python -c "import pymod"
Fatal Python error: _PyInterpreterState_GET: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL)
Python runtime state: unknown
WinDbg jit debugger then catches the issue. A partial call stack shows my PyInit_pymod is called and when creating the python module, it cascades to a failure:
0:000> k
# Child-SP RetAddr Call Site
00 000000dc`abfed4a8 00007fff`71d51385 KERNELBASE!wil::details::DebugBreak+0x2
01 000000dc`abfed4b0 00007fff`71d511a8 python39_d!fatal_error_exit+0x15 [D:\a\1\s\Python\pylifecycle.c # 2201]
02 000000dc`abfed4e0 00007fff`71d4ea98 python39_d!fatal_error+0x1b8 [D:\a\1\s\Python\pylifecycle.c # 2286]
03 000000dc`abfed540 00007fff`71cbe730 python39_d!_Py_FatalErrorFunc+0x38 [D:\a\1\s\Python\pylifecycle.c # 2302]
04 000000dc`abfed580 00007fff`71aa8044 python39_d!_Py_FatalError_TstateNULL+0x10 [D:\a\1\s\Python\ceval.c # 251]
05 000000dc`abfed5b0 00007fff`71aa6cf2 python39_d!_PyInterpreterState_GET+0x34 [D:\a\1\s\Include\internal\pycore_pystate.h # 105]
06 000000dc`abfed5f0 00007fff`d0be13e7 python39_d!PyModule_Create2+0x12 [D:\a\1\s\Objects\moduleobject.c # 168]
>>>> 07 000000dc`abfed620 00007fff`751165dc pymod!PyInit_pymod+0x27 [E:\projects\pymod\pymodmodule.cpp # 19]
08 000000dc`abfed660 00007fff`751167ee python39!_PyImport_LoadDynamicModuleWithSpec+0x104 [C:\A\34\s\Python\importdl.c # 165]
09 000000dc`abfed6d0 00007fff`75116749 python39!_imp_create_dynamic_impl+0x86 [C:\A\34\s\Python\import.c # 2299]
0a 000000dc`abfed700 00007fff`750cb94b python39!_imp_create_dynamic+0x39 [C:\A\34\s\Python\clinic\import.c.h # 330]
0b 000000dc`abfed730 00007fff`750ad500 python39!cfunction_vectorcall_FASTCALL+0x9b [C:\A\34\s\Objects\methodobject.c # 426]
0c 000000dc`abfed7a0 00007fff`750ad2ef python39!PyVectorcall_Call+0x5c [C:\A\34\s\Objects\call.c # 248]
0d 000000dc`abfed800 00007fff`750ad418 python39!_PyObject_Call+0x4f [C:\A\34\s\Objects\call.c # 287]
0e (Inline Function) --------`-------- python39!PyObject_Call+0xc [C:\A\34\s\Objects\call.c # 293]
0f 000000dc`abfed830 00007fff`7508c65f python39!do_call_core+0xb8 [C:\A\34\s\Python\ceval.c # 5092]
10 000000dc`abfed880 00007fff`75083963 python39!_PyEval_EvalFrameDefault+0x5d6f [C:\A\34\s\Python\ceval.c # 3581]
11 (Inline Function) --------`-------- python39!_PyEval_EvalFrame+0x13 [C:\A\34\s\Include\internal\pycore_ceval.h # 40]
12 000000dc`abfedbb0 00007fff`750855a7 python39!_PyEval_EvalCode+0x2b3 [C:\A\34\s\Python\ceval.c # 4327]
13 000000dc`abfedc80 00007fff`7508823d python39!_PyFunction_Vectorcall+0x257 [C:\A\34\s\Objects\call.c # 396]
14 000000dc`abfedd80 00007fff`7508812f python39!_PyEval_EvalFrameDefault+0x194d [C:\A\34\s\Python\ceval.c # 3487]
15 000000dc`abfee0b0 00007fff`750888e5 python39!_PyEval_EvalFrameDefault+0x183f [C:\A\34\s\Python\ceval.c # 3504]
16 000000dc`abfee3e0 00007fff`750888e5 python39!_PyEval_EvalFrameDefault+0x1ff5 [C:\A\34\s\Python\ceval.c # 3518]
17 000000dc`abfee710 00007fff`750888e5 python39!_PyEval_EvalFrameDefault+0x1ff5 [C:\A\34\s\Python\ceval.c # 3518]
18 000000dc`abfeea40 00007fff`750854c4 python39!_PyEval_EvalFrameDefault+0x1ff5 [C:\A\34\s\Python\ceval.c # 3518]
I cannot find any information on the console message, nor the int3. I have tried full purge and reinstall/update of Python.
Can anyone offer some direction to help, or know the cause?
Edit: Modified that PyModule_pymod function to display Pre and Post msg to console. Debug build exceptions, Release appears not to:
PyMODINIT_FUNC PyInit_pymod(void) {
printf("Pre-PyModule_Create\n");
PyObject *obj = PyModule_Create(&pymodmodule);
printf("Post-PyModule_Create\n");
return obj;
}
Release:
E:\projects\pymod\build\Release>python -c "import pymod"
Pre-PyModule_Create
Post-PyModule_Create
Debug:
E:\projects\pymod\build\Debug>python -c "import pymod"
Pre-PyModule_Create
Fatal Python error: _PyInterpreterState_GET: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL)
Python runtime state: unknown
I ran into the same issue as you, and while debugging TLS structures, I noticed that Visual Studio had loaded python310.dll instead of python310_d.dll.
To make a long story short, when you define the _DEBUG macro, Python.h will use python310_d.lib, so you need to run the debug version of Python:
python_d -c "import pymod"
I was confused further by the fact that I did not have this issue while using pybind11. As it turned out, pybind11 undefines the _DEBUG macro while including Python.h, so it is always using python310.lib instead of python310_d.lib, even for debugging builds.
As I do not see an option to use the python_d interpreter in Visual Studio, I ended up using the release library for debugging builds using the following code:
#if defined(_MSC_VER) && defined(_DEBUG)
#undef _DEBUG
#include <Python.h>
#define _DEBUG 1
#else
#include <Python.h>
#endif
As a sidenote, when you link against python310_d.dll, you will have to name your debug module pymod_d.pyd instead of pymod.pyd.

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

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

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

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.