Unhandled Exception: Cannot print exception string because Exception.ToString() failed.

[rconde01]

Ok - i'm trying to invest more time into figuring out all my vld crash issues. I ran into a new issue:

• 2.5 release
• x86
• debug
• w/o MFC project
• I changed the toolset to the non-xp variant
• Visual Studio 2015 Update 3
• Application is .NET which pulls in C++/CLI dlls and pure native dlls
• Windows 10 x64

On launch I'm getting: Unhandled Exception: Cannot print exception string because Exception.ToString() failed.

This happens nearly every time when launching independently, but more rarely when launching through the debugger.

Here is the call stack:

    vld_x86.dll!FindRealCode(void * pCode=0x006ee830) Line 433  C++
>   vld_x86.dll!PatchImport(HINSTANCE__ * importmodule=0x00ea0000, moduleentry_t * patchModule=0x0b736108) Line 551 C++
    vld_x86.dll!PatchModule(HINSTANCE__ * importmodule=0x00ea0000, moduleentry_t * patchtable=0x0b736108, unsigned int tablesize=58) Line 666   C++
    vld_x86.dll!VisualLeakDetector::attachToLoadedModules(Set<moduleinfo_t> * newmodules=0x0ba10858) Line 885   C++
    vld_x86.dll!VisualLeakDetector::VisualLeakDetector() Line 483   C++
    vld_x86.dll!`dynamic initializer for 'g_vld''() Line 61 C++
    vld_x86.dll!_initterm(void(*)() * first=0x0b6e8000, void(*)() * last=0x0b6e831c) Line 22    C++
    vld_x86.dll!dllmain_crt_process_attach(HINSTANCE__ * const instance=0x0b5b0000, void * const reserved=0x00000000) Line 65   C++
    vld_x86.dll!dllmain_crt_dispatch(HINSTANCE__ * const instance=0x0b5b0000, const unsigned long reason=1, void * const reserved=0x00000000) Line 133  C++
    vld_x86.dll!_CRT_INIT(HINSTANCE__ * const instance=0x0b5b0000, const unsigned long reason=1, void * const reserved=0x00000000) Line 150 C++
    vld_x86.dll!DllEntryPoint(HINSTANCE__ * hinstDLL=0x0b5b0000, unsigned long fdwReason=1, void * lpReserved=0x00000000) Line 277  C++

The crash is here:

if (*(WORD *)pCode == 0x25ff) // JMP r/m32

This is while patching kernelbase.dll

I will try to make a small repo case...not sure if this is related to:

https://github.com/KindDragon/vld/commit/6716c760a0e4e47398c362e2c8684f0e0aa1c188

[rconde01]

Ok - I have a minimally reproducible case more_vld_tests.zip

To run the test:

• open and build vld_vs14_wo_mfc.sln in debug x86 and debug x64
• copy vld-2.5/setup/dbghelp/x86/. to vld-2.5/bin/x86
• copy vld-2.5/setup/dbghelp/x64/. to vld-2.5/bin/x64
• add vld-2.5/bin/x86 and vld-2.5/bin/x64 to the path
• open MRC/TestBed/TestBed.sln
• build x86 debug
• debug

x86 gets the crash above. x64 gets a crash in NtDll.dll

I also testing in a simple win32 application. x86 works fine. x64 crashes as above.

My thought is that the x64 problem is the other bug. I'm going to grab that branch and test with that.

[rconde01]

Neither problem is fixed by applying:

https://github.com/KindDragon/vld/commit/6716c760a0e4e47398c362e2c8684f0e0aa1c188

[rconde01]

For 32-bit, if I add:

    if (_wcsicmp(TEXT("testbed.exe"), modulename) == 0) {
       continue;
    }

to attachToLoadedModule, it appears to work as expected

[rconde01]

The 64-bit is crashing on:

        LPVOID import = VisualLeakDetector::_RGetProcAddress(exportmodule, importname);

where the exportmodule is ucrtbased.dll and importname = _calloc_dbg

[rconde01]

This was fixed by applying:

https://github.com/ioannis-e/vld/tree/win10_1607

Now I'm getting a stack overflow...but i'll open a different issue for that.

[rconde01]

Ok - I got confused here with the anniversary update crash. This still crashes in x86.

[ioannis-e]

@rconde01 A couple of things to try and consider

1. First add a reference in the TestBed project to NativeDll project to ensure that both binaries are built.
2. Make sure that you copy all vld_xYY.dll and Microsoft.DTfW.DHL.manifest and dbghelp.dll to .\MRC\TestBed\bin\x86\Debug and .\MRC\TestBed\bin\x64\Debug respectively.

NativeDll.dll is statically linked with vld_xYY.dll, which is statically linked with dbghelp.dll, so if all these dlls cannot be found NativeDll.dll will fail to load and lead to a crash.

Finally, i am no expert but, vld is designed to trace native code not managed code memory allocations. In your case almost all allocations reported are made internally by clr.dll. So i guess this will not be much help unless you ignore allocations made by the managed code dlls. At this point vld has no way of hooking into managed code dll imports so even something like https://msdn.microsoft.com/en-us/library/aa664786(v=vs.71).aspx would not be traced properly by vld.

Would be great if you let us know what you are trying to achieve.

[rconde01]

@ioannis-e Things work as expected in x64 so I don't think it's a configuration issue but I will double check. I don't expect this to work for managed memory leaks. I have an application where all the GUI is .NET, but most of the program logic is in C++. I just expect to get memory leaks for the C++ bits (which are pulling in vld).

This was just a minimally reproducible case - the actual application is dominated by native allocations.

Also, to reiterate from above, exempting the exe in attachToLoadedModule appears to fix the issue and then things work as expected.

[rconde01]

@ioannis-e Ok I confirmed that my config is good. When the crash occurs the modules list shows dbghelp.dll, vld_x86.dll, and NativeDll.dll all loaded. I should have specified from the original config that I have the directory containing vld_x86.dll, dbghelp.dll etc in my path...so it's not necessary to copy them.

If you need me to make the example a bit more straightforward to run let me know.

[WildCard65]

I'm throwing something onto this, I'm working on a project ( not project specified in #22 ) that is a C++ CLR dll linked with a static library of pure native code that is linked with zlib 1.2.8, running the x86 dll resulted in an access violation at https://github.com/KindDragon/vld/blob/master/src/utility.cpp#L666