kinddragon / vld

Visual Leak Detector for Visual C++ 2008-2015

Visual Leak Detector

⚠️ Project Status: Inactive ⚠️

This project is currently not in active development. The author is focusing on Linux development and is not maintaining this project at the moment.

🔍 Seeking Maintainers: If you are interested in becoming a maintainer and contributing to this project, please feel free to reach out. Your contributions would be greatly appreciated!

Introduction

Visual C++ provides built-in memory leak detection, but its capabilities are minimal at best. This memory leak detector was created as a free alternative to the built-in memory leak detector provided with Visual C++. Here are some of Visual Leak Detector's features, none of which exist in the built-in detector:

• Provides a complete stack trace for each leaked block, including source file and line number information when available.
• Detects most, if not all, types of in-process memory leaks including COM-based leaks, and pure Win32 heap-based leaks.
• Selected modules (DLLs or even the main EXE) can be excluded from leak detection.
• Provides complete data dumps (in hex and ASCII) of leaked blocks.
• Customizable memory leak report: can be saved to a file or sent to the debugger and can include a variable level of detail.

Other after-market leak detectors for Visual C++ are already available. But most of the really popular ones, like Purify and BoundsChecker, are very expensive. A few free alternatives exist, but they're often too intrusive, restrictive, or unreliable. Visual Leak Detector is currently the only freely available memory leak detector for Visual C++ that provides all of the above professional-level features packaged neatly in an easy-to-use library.

Visual Leak Detector is licensed free of charge as a service to the Windows developer community. If you find it to be useful and would like to just say "Thanks!", or you think it stinks and would like to say "This thing sucks!", please feel free to drop us a note. Or, if you'd prefer, you can contribute a small donation. Both are very appreciated.

Documentation

Read the documentation at https://github.com/KindDragon/vld/wiki

Contributing

We encourage developers who've added their own features, or fixed bugs they've found, to contribute to the project. The full version-controlled source tree is available publicly via Git at the URL below. Feel free to clone from this URL and submit patches for consideration for inclusion in future versions. You can also issue pull requests for changes that you've made and would like to share.

• Source code

Copyright © 2005-2017 VLD Team

vld's Issues

Is vld working correctly with managed applications?

I like the tool for it's simplicity.
But should it work properly with managed applications?

I'm using VS2010, .NET 4.0, and a mixed application (i.e. managed and unmanged code).

VLD infinite method call loop

VLD runs into an infinite loop when it calls TlsGetValue during it's HeapAlloc hook

Can Qt use VLD?

I'm trying to use VLD on Qt5.9.1 for windows! Microsoft Visual C++ Compiler 14.0 (amd64). But it always causes abnormal exits of the program. I don't clear up what's going on.

So the project was dead

So long time,no commit

crash when dll add shell

hi, i'm now use a dll add shell such as 'yoda's Protector v1.02' or 'ACProtect 1.3x',
(i 'm test library bass, it's a shell dll, website: http://www.un4seen.com/bass.html)
and when i call 'LoadLibrary' and load these dll, the program crash.
i track and debug the source, the vld hook the dll load and do 'attachToLoadedModules()' with each dll(can't patch function malloc() and free()).

bacause the dll add shell, so vld patch failed. i wish vld add some function:
add a file vld.config, it contian excluded dll name?

thanks!

Visual Studio 2017 support please

I'm not sure if anyone is maintaining any version of vld anymore, but 2017 has been out for a while now and there is no support for it yet. Any insight on if this will be added eventually would be appreciated.

Failing Build

I notice the state of the build is failing lately.
Couple that with a non-transparent CI/CD System, we don't have current build states for any Pull Requests either. @KindDragon Can you give me some added credentials into the CI/CD system for appveyor you put together? If not, I can easily put one together for Azure Devops that I have done for other projects.

Anyways, perhaps this can be a conversation for further needs and goals for CI/CD for this project.

Broken build in VS2013

b195c32 has broken build in VS2013
Tried to fix with f82e148 but fails in appveyor

Where's the explanation please?

Hi,
Did I miss any Visual Leak Detector documentation which explain precisely what the lines at the bottom of the VLD report such as "Total allocations" and "Largest number used" mean?
Feedback appreciated, but can I request that you strive further to use unambiguous language because I'm having difficulty understanding these existing phrases (for example, does "Largest number used" mean "the sum total of all allocations ever made by the program's run" or "the maximum size of the heap from which allocations can be made"?).
Sincere thanks in advance.
M. Henning

VLD: New allocation at already allocated address from realloc()

It's maybe working as intented but then it'll raise it anyway.
Found this discussed here https://gitter.im/KindDragon/vld/archives/2016/01/14
but answer link is no longer accessible.

In a multithreaded application calling realloc()/malloc()
Thread 1: realloc() -> HeapReAlloc() -> block X is freed for the Heap, will give block Y
Thread2: malloc() -> HeapAlloc() -> block X is given back
But the trackings done in CaptureContext::~CaptureContext() wrapper will happen later, resulting in "VLD: New allocation at already allocated address" Reported in remapBlock().

This is maybe a potential problem if the following sequence then occurs
Thread2: mapBlock X (+ warning)
Thread1: unmapBlock X
Thread1: mapBlockY

Could then block X reference be lost ?

Note that the sizes might still differ. HeapAlloc() does sometimes give back the same buffer even if sizes are slightly differnts.

As that warning was suspicious and "probably by some mechanism unknown to VLD" comment not encouraging, I added an unmapBlock() before the call in _RtlReAllocateHeap()/_HeapReAlloc() wrappers as already done in _RtlFreeHeap/_HeapFree.

This somehow renders remapBlock() mechanism irrelevant in this scenario.

`LPVOID VisualLeakDetector::_RtlReAllocateHeap (HANDLE heap, DWORD flags, LPVOID mem, SIZE_T size)
{
PRINT_HOOKED_FUNCTION();

if (!g_DbgHelp.IsLockedByCurrentThread()) // skip dbghelp.dll calls
{
    // Record the current frame pointer.
    CAPTURE_CONTEXT();
    context_.func = reinterpret_cast<UINT_PTR>(RtlReAllocateHeap);

    // Unmap the block from the specified heap.
    g_vld.unmapBlock(heap, mem, context_);
}

 // Reallocate the block.
 LPVOID newmem = RtlReAllocateHeap(heap, flags, mem, size);
if ((newmem == NULL) || !g_vld.enabled())
    return newmem;

if (!g_DbgHelp.IsLockedByCurrentThread()) { // skip dbghelp.dll calls
    CAPTURE_CONTEXT();
    CaptureContext cc(RtlReAllocateHeap, context_);
    cc.Set(heap, mem, newmem, size);
}

return newmem;

}

// for kernel32.dll
LPVOID VisualLeakDetector::_HeapReAlloc (HANDLE heap, DWORD flags, LPVOID mem, SIZE_T size)
{
PRINT_HOOKED_FUNCTION();

if (!g_DbgHelp.IsLockedByCurrentThread()) // skip dbghelp.dll calls
{
    // Record the current frame pointer.
    CAPTURE_CONTEXT();
    context_.func = reinterpret_cast<UINT_PTR>(HeapReAlloc);

    // Unmap the block from the specified heap.
    g_vld.unmapBlock(heap, mem, context_);
}

// Reallocate the block.
LPVOID newmem = HeapReAlloc(heap, flags, mem, size);
if ((newmem == NULL) || !g_vld.enabled())
    return newmem;

if (!g_DbgHelp.IsLockedByCurrentThread()) { // skip dbghelp.dll calls
    CAPTURE_CONTEXT();
    CaptureContext cc(HeapReAlloc, context_);
    cc.Set(heap, mem, newmem, size);
}

return newmem;

}`

I was looking at a heap corruption and this Report warning was my only lead.
I found out later that it was #26
Thanks @rglarix for your patches

direct/indirect leaks

Does/could vld distinguish between direct and indirect leaks like LeakSanitizer does?

VLD makes app launch extremely slow

Due to 8010efe starting program becomes incredibly slow. My program spends several minutes in CaptureContext::IsExcludedModule, the time is taken by VirtualQuery function which is called by GetCallingModule. I think in current state it's unacceptable and should be fixed.

vld2.5.1 Application start up failed because of access violation VS2015 Update3

Hello, could anyone help me?

There is a rare problem troubled me. I'm checking memory leak of my vs2015 solution with vld2.5.1.
I have tried to check one simple vs2015 project,and the vld works well.But when I use vld to check our project that include about 100 subprojects, the generated application started up failed. (the application need to load some dlls) .

The phenomenon is a break dialog pop out and the info is a access vilolation exception:
0x0000000003241099 (vld_x64.dll) 0xC0000005: read location 0x00000000001C9D4A

This is the callstack info:

vld_x64.dll!FindRealCode(void * pCode) 行 433 C++
vld_x64.dll!PatchImport(HINSTANCE__ * importmodule, moduleentry_t * patchModule) 行 551 C++
vld_x64.dll!PatchModule(HINSTANCE__ * importmodule, moduleentry_t * patchtable, unsigned int tablesize) 行 668 C++
vld_x64.dll!VisualLeakDetector::attachToLoadedModules(Set<moduleinfo_t> * newmodules) 行 904 C++
vld_x64.dll!VisualLeakDetector::RefreshModules() 行 2332 C++
vld_x64.dll!LdrpCallInitRoutine(void * BaseAddress, unsigned long Reason, void * Context, unsigned char(*)(void *, unsigned long, _CONTEXT *) EntryPoint) 行 98 C++

So,I tried to debug vld's source code to find the reason.And I found that in the utility.cpp in PatchImport function (line 489) ,when "importmodule == MagiQpdSrv_x64_nc_fw40_15001.dll " ,
program break off in LPVOID func = FindRealCode((LPVOID)thunk->u1.Function);(line 551).
At the same time, Function Parameter "(LPVOID)thunk->u1.Function" is a wild pointer. So program break off in function FindRealCode.

Does anyone know the solution for my problem?Thanks very much and look forward to a reply!

vstest.executionengine.x86.exe along with VLD

I encountered an issue using Microsoft Test Engine vstest.executionengine.x86.exe for C++ using along with VLD. I use VLD 2.5.1. I have my lib which is build as Debug and included vld.h header file. When I start a test from Visual studio, the program (vstest.executionengine.x86.exe ) got stopped by unhandled exception in vld_x64.dll access violation reading lcoation with next call stack.. I tried a simple console application to test vld and it works fine. Is VLD work with VS c++ framework?

VLD Crashes

I'm getting crashes every few times running vld 2.5 (although I also get crashes with vld 2.3 and 2.4). If needed I can later give more exhaustive information about my configuration, but I have a primary issue to bring up first. When my application starts vld reports several "New allocation at already allocated address" messages. When it crashes, it crashes on the getCrtBlockUse call in reportLeaks.

Based on the comment in mapBlock:

//block with this address has already been allocated. The
// previously allocated block must have been freed (probably by some
// mechanism unknown to VLD), or the heap wouldn't have allocated it
// again. Replace the previously allocated info with the new info.

I had the following thought.

If this "unknown mechanism" is unallocating memory, then if it unallocates it and never reallocates it, the block map will stale and the contained block will no longer be valid. Then when that block is accessed you will get a crash.

I may be wrong, but my current guess is that this is the cause of my crashes. Any ideas how it could be fixed?

I'm using Visual Studio 2013, Win10, 64-bit.

Installation of 2.5.1 on 32-bit Windows 7 fails

The v2.5.1 installer fails on 32-bit Windows 7 with an 'Internal error: Cannot access 64-bit registry keys on this version of Windows'. The v2.4rc2 installer runs without errors.

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

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:

6716c76

False positives detected for static member std::string

I have a class that defines a static member:
class RawDecoder { public: static std::string cam_profile; };
declared as
std::string RawDecoder::cam_profile;
which is reported as a leak
CRT Alloc ID: 195 Leak Hash: 0x46AD681D, Count: 1, Total 16 bytes Call Stack (TID 5096): ucrtbased.dll!malloc() d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\heap\new_scalar.cpp (35): Phot.exe!operator new() + 0xA bytes C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xmemory (52): Phot.exe!std::_Default_allocate_traits::_Allocate() C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xmemory (180): Phot.exe!std::_Allocate<16,std::_Default_allocate_traits,0>() + 0xA bytes C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xmemory (785): Phot.exe!std::allocator<std::_Container_proxy>::allocate() C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xmemory (1098): Phot.exe!std::_Container_base12::_Alloc_proxy<std::allocator<std::_Container_proxy> >() + 0xF bytes C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xstring (2286): Phot.exe!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> >() + 0x30 bytes C:\Users\drogers\Documents\Visual Studio 2010\Projects\ImageViewers\dcraw\dcraw.cpp (116): Phot.exe!dynamic initializer for 'RawDecoder::cam_profile''() + 0x10 bytes
`

Option to enable vld for release builds

If it is technically possible, it would be great to have the possibility to link and use VLD in your release build (of course with an option which is set to off by default).

This would then allow e.g. adding a call parameter to one's console application enableMemoryLeakDetection which could then be set by a Continuous Integration testing server to examine if new code caused new memory leaks.

General Usage

Maybe I miss something but where is the documentation how to use the output of vld?

I get a block of:
---------- Block 909 at 0x01A55190: 52 bytes ---------- Leak Hash: 0xE56AF3DE, Count: 1, Total 52 bytes Call Stack (TID 11744): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxmem.cpp (302): FoxSDKU32w_dbg.dll!operator new() + 0xF bytes d:\development\6.8.4\development\sdk\framework\klogger.cpp (165): FoxSDKU32w_dbg.dll!ILogger::instance() + 0x7 bytes d:\development\6.8.4\development\sdk\callbacks.cpp (177): FoxSDKU32w_dbg.dll!CallBacks::Reset() + 0x5 bytes d:\development\6.8.4\development\sdk\callbacks.cpp (43): FoxSDKU32w_dbg.dll!CallBacks::CallBacks() d:\development\6.8.4\development\sdk\foxburner.cpp (83): FoxSDKU32w_dbg.dll!NewSDK::FoxBurner::FoxBurner() + 0x1A bytes d:\development\6.8.4\development\sdk\export.cpp (153): FoxSDKU32w_dbg.dll!Initialize() + 0x1E bytes d:\development\6.8.4\samples\c++\utilitiesmfc\utilitiesmfcdlg.cpp (84): FoxUtilitiesSampleUw_dbg.exe!CUtilitiesMFCDlg::OnInitDialog() + 0xD bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp (28): FoxUtilitiesSampleUw_dbg.exe!AfxDlgProc() + 0x6 bytes USER32.dll!AddClipboardFormatListener() + 0x49B bytes USER32.dll!GetScrollInfo() + 0x10F3 bytes USER32.dll!GetScrollInfo() + 0x7A7 bytes USER32.dll!GetScrollInfo() + 0x6C8 bytes USER32.dll!AddClipboardFormatListener() + 0x49B bytes USER32.dll!DispatchMessageW() + 0x97A bytes USER32.dll!CallWindowProcW() + 0x8D bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp (1100): FoxUtilitiesSampleUw_dbg.exe!CWnd::DefWindowProcW() + 0x22 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp (297): FoxUtilitiesSampleUw_dbg.exe!CWnd::Default() + 0x6 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp (721): FoxUtilitiesSampleUw_dbg.exe!CDialog::HandleInitDialog() + 0x8 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp (2441): FoxUtilitiesSampleUw_dbg.exe!CWnd::OnWndMsg() + 0x9 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp (2099): FoxUtilitiesSampleUw_dbg.exe!CWnd::WindowProc() + 0x6 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp (265): FoxUtilitiesSampleUw_dbg.exe!AfxCallWndProc() + 0x6 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp (418): FoxUtilitiesSampleUw_dbg.exe!AfxWndProc() USER32.dll!AddClipboardFormatListener() + 0x49B bytes USER32.dll!DispatchMessageW() + 0x97A bytes USER32.dll!SendMessageW() + 0x3AA bytes USER32.dll!SetWindowRgn() + 0xC26 bytes USER32.dll!CreateDialogIndirectParamAorW() + 0x35 bytes USER32.dll!CreateDialogIndirectParamW() + 0x1B bytes f:\dd\externalapis\windows\10\sdk\inc\winuser.inl (569): FoxUtilitiesSampleUw_dbg.exe!IsolationAwareCreateDialogIndirectParamW() + 0x1C bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp (358): FoxUtilitiesSampleUw_dbg.exe!CWnd::CreateDlgIndirect() + 0x29 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp (460): FoxUtilitiesSampleUw_dbg.exe!CWnd::CreateRunDlgIndirect() + 0x14 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp (633): FoxUtilitiesSampleUw_dbg.exe!CDialog::DoModal() + 0x20 bytes d:\development\6.8.4\samples\c++\utilitiesmfc\utilitiesmfc.cpp (63): FoxUtilitiesSampleUw_dbg.exe!CUtilitiesMFCApp::InitInstance() + 0xB bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp (37): FoxUtilitiesSampleUw_dbg.exe!AfxWinMain() + 0x6 bytes f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\appmodul.cpp (26): FoxUtilitiesSampleUw_dbg.exe!wWinMain() f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl (123): FoxUtilitiesSampleUw_dbg.exe!invoke_main() f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl (283): FoxUtilitiesSampleUw_dbg.exe!__scrt_common_main_seh() + 0x5 bytes f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl (326): FoxUtilitiesSampleUw_dbg.exe!__scrt_common_main() f:\dd\vctools\crt\vcstartup\src\startup\exe_wwinmain.cpp (17): FoxUtilitiesSampleUw_dbg.exe!wWinMainCRTStartup() KERNEL32.DLL!BaseThreadInitThunk() + 0x24 bytes ntdll.dll!RtlAreBitsSet() + 0x88 bytes ntdll.dll!RtlAreBitsSet() + 0x58 bytes Data: C8 5C 8D 10 C0 69 8E 10 00 04 00 00 00 11 00 00 .\...i.. ........ 00 1C 00 00 00 11 00 00 90 38 AA 01 01 CD CD CD ........ .8...... 00 00 00 00 2C 1F 8D 10 A0 3B A5 01 60 72 A5 01 ....,... .;..r..
00 00 00 00 ........ ........`

How I can read this block to find the problem?

VLD generates no report/output

VLD generates no report/output at the end of the program. This occurs with Studio 2015 and Visual Studio 2017.

The debug output shows the following information at the startup of the application:
Loaded 'D:\Visual Leak Detector\bin\Win32\vld_x86.dll'. Symbols loaded.
Unloaded 'D:\Visual Leak Detector\bin\Win32\vld_x86.dll'
Loaded 'D:\Visual Leak Detector\bin\Win32\vld_x86.dll'. Symbols loaded.
Loaded 'D:\Visual Leak Detector\bin\Win32\dbghelp.dll'. Cannot find or open the PDB file.
Unloaded 'D:\Visual Leak Detector\bin\Win32\dbghelp.dll'
Loaded 'D:\Visual Leak Detector\bin\Win32\dbghelp.dll'. Cannot find or open the PDB file.
Visual Leak Detector read settings from: D:\Visual Leak Detector\vld.ini
Visual Leak Detector Version 2.5.1 installed.
Outputting the report to the debugger and to D:\Visual Leak Detector\VLD_Report.txt
Performing a memory leak self-test.

At the end of the application the output shows some memory leaks:
Detected memory leaks!
Dumping objects ->
{59966} normal block at 0x0D1D6BF0, 16911 bytes long.
Data: < k > CD CD CD CD CD CD CD CD FA FA FA FA F0 6B 1D 0D
{59965} normal block at 0x0D1C8B88, 86 bytes long.
Data: < ! " > D8 AC F3 0C 21 00 00 00 22 00 00 00 01 00 00 00
{59964} normal block at 0x0D2C3358, 96 bytes long.
Data: < ' > D8 AC F3 0C 1F 00 00 00 27 00 00 00 01 00 00 00
{59963} normal block at 0x0D2C2FF8, 98 bytes long.

This is not the VLD output/report.

The file specified in the VLD.ini was created during startup but remains empty.

Windows 10 (x64, Version 1803)
Visual Studio 2015 Professional
Visual Studio 2017 Professional
Latest version von VLD (2.5.1)
Tried several dbghelp.dll from Program-Files, without any result.

dynamic_app test StackWalkMethod=safe Release sometimes crash

Test DynamicLoader.MultithreadLoadingTests 😢

    ntdll.dll!RtlpFreeHeap()    Unknown
    ntdll.dll!_RtlFreeHeap@12�()    Unknown
>   vld_x86.dll!VisualLeakDetector::_RtlFreeHeap(void * heap, unsigned long flags, void * mem) Line 237 C++
    msvcrt.dll!_free�() Unknown
    dbghelp.dll!operator delete[](void *)   Unknown
    dbghelp.dll!NMT::~NMT(void) Unknown
    dbghelp.dll!NMP::`scalar deleting destructor'(unsigned int) Unknown
    dbghelp.dll!NMP::close(void)    Unknown
    dbghelp.dll!CDiaSession::~CDiaSession(void) Unknown
    dbghelp.dll!CDiaSession::`scalar deleting destructor'(unsigned int) Unknown
    dbghelp.dll!ObjSymBase::Release(void)   Unknown
    dbghelp.dll!CDiaSymbol::Release(void)   Unknown
    dbghelp.dll!CDiaFrameData::~CDiaFrameData(void) Unknown
    dbghelp.dll!CDiaFrameData::`scalar deleting destructor'(unsigned int)   Unknown
    dbghelp.dll!ObjSymBase::Release(void)   Unknown
    dbghelp.dll!CDiaSymbol::Release(void)   Unknown
    dbghelp.dll!DbhStackServices::FreeUnwindInfoFromSymbols(void *,unsigned long)   Unknown
    dbghelp.dll!DbsStackServices::UnwindInfoHolder::~UnwindInfoHolder(void) Unknown
    dbghelp.dll!DbsX86StackUnwinder::ApplyUnwindInfo(void)  Unknown
    dbghelp.dll!DbsX86StackUnwinder::Unwind(void)   Unknown
    dbghelp.dll!DbsStackUnwinder::DbhUnwind(struct _tagSTACKFRAME64 *,unsigned long,void *,unsigned long,void *)    Unknown
    dbghelp.dll!PickX86Walk(class DbsStackUnwinder *,class DbhStackServices *,struct _tagSTACKFRAME64 *,void *) Unknown
    dbghelp.dll!_StackWalk64@36�()  Unknown
    vld_x86.dll!SafeCallStack::getStackTrace(unsigned int maxdepth, const context_t & context) Line 797 C++
    vld_x86.dll!CaptureContext::~CaptureContext() Line 2902 C++
    vld_x86.dll!CrtPatch<140,0>::crtd_malloc(unsigned int size) Line 461    C++
    dynamic.dll!allocator<0>::alloc(LeakOption type, bool) Line 82  C++
    dynamic.dll!SimpleLeak_Malloc() Line 17 C++
    dynamic_app.exe!RunLoaderTests(bool resolve) Line 55    C++
    dynamic_app.exe!Dynamic_Thread_Procedure(void * foo) Line 60    C++
    ucrtbase.dll!__crt_at_quick_exit�() Unknown
    kernel32.dll!@BaseThreadInitThunk@12�() Unknown
    ntdll.dll!__RtlUserThreadStart()    Unknown
    ntdll.dll!__RtlUserThreadStart@8�() Unknown

Unhandled exception at 0x77BC1797 (ntdll.dll) in dynamic_app.exe: 0xC0000005: Access violation reading location 0x00000000.

v140

/cc @ioannis-e @akaStiX

Visual studio 2017 integration

Hi, is it possible to get a vs17 integration started, I don't mind contributing.
Thanks,
Jamie

VS2008 only output "New allocation at already allocated address:"

Hello, everyone:

I use VLD in several projects under Visual Studio 2008(64bit). I have integrated it to my new project but it seems doesn't work at all.

I run the project in debug mode.

The output window only has:

VLD: New allocation at already allocated address: 0x0000000001E7CA00 with size: 576 and new size: 564

I can not see this message in other projects.

I also modify the vld.ini file and set [ReportTo] to both.

But the output file is empty.

Any help will be appreciated.

Debug dll error

Sketchup ruby C extension

Fix Release_StaticCrt tests

Previous work on PR #8

Doesn't work v90-v110 Release_StaticCrt tests

Current build results https://ci.appveyor.com/project/KindDragon/vld/build/134

/cc @ioannis-e

Microsoft.Cpp.XXX.user.props Installation

I was wandering whether it is possible for the installer to use the following "better" way of installing VLD in Microsoft.Cpp.Win32.user.props and Microsoft.Cpp.x64.user.props instead of how its done now (commented below).
These paths are global and using Additional...Directories which are per project/configuration pollutes the entry.

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="UserMacros">
    <VLD_INCLUDE>C:\Program Files (x86)\Visual Leak Detector\include</VLD_INCLUDE>
    <VLD_SRC>C:\Program Files (x86)\Visual Leak Detector\src</VLD_SRC>
    <VLD_LIB_x86>C:\Program Files (x86)\Visual Leak Detector\lib\Win32</VLD_LIB_x86>
    <VLD_LIB_x64>C:\Program Files (x86)\Visual Leak Detector\lib\Win64</VLD_LIB_x64>
  </PropertyGroup>
  <PropertyGroup>
    <IncludePath>$(VLD_INCLUDE);$(IncludePath)</IncludePath>
    <LibraryPath>$(VLD_LIB_x86);$(LibraryPath)</LibraryPath>
    <SourcePath>$(VLD_SRC);$(SourcePath)</SourcePath>
  </PropertyGroup>
  <ItemGroup>
    <BuildMacro Include="VLD_INCLUDE"><Value>$(VLD_INCLUDE)</Value><EnvironmentVariable>true</EnvironmentVariable></BuildMacro>
    <BuildMacro Include="VLD_SRC"><Value>$(VLD_SRC)</Value><EnvironmentVariable>true</EnvironmentVariable></BuildMacro>
    <BuildMacro Include="VLD_LIB_x86"><Value>$(VLD_LIB_x86)</Value><EnvironmentVariable>true</EnvironmentVariable></BuildMacro>
    <BuildMacro Include="VLD_LIB_x64"><Value>$(VLD_LIB_x64)</Value><EnvironmentVariable>true</EnvironmentVariable></BuildMacro>
  </ItemGroup>
<!--
  <ItemDefinitionGroup>
    <ClCompile>
      <AdditionalIncludeDirectories>C:\Program Files (x86)\Visual Leak Detector\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
    </ClCompile>
    <Link>
      <AdditionalLibraryDirectories>C:\Program Files (x86)\Visual Leak Detector\lib\Win32;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
    </Link>
    <Lib>
      <AdditionalLibraryDirectories>C:\Program Files (x86)\Visual Leak Detector\lib\Win32;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
    </Lib>
  </ItemDefinitionGroup>
-->
</Project>

Vld included and compiled successfully, and activated (vld.ini) but no report is generated. with Visual Studio 2012.

Hi,

I have

• download and install latest VLD release
• include vld.h in my code and link with vld library
• add void VLDEnable (); in my code
• check that vld is on in vld.ini (VLD = on)
• specify a file name in vld.ini ReportFile = (C:\tmp\vld.txt)
• specify both to have debugger and file reporting (ReportTo = both)
• stop and restart visual studio 2012. Version 11.0.5
  But still not able to generate any report or any file.
  Any help would be appreciated.
  Thanks,

Binaries for Windows after CodePlex is going read-only

Since CodePlex is going read-only the binaries hosted over here surely won't get updated I assume? I wanted to know whether you are going to host those binaries here on GitHub as well.

vld2.5.1 can't support QT5.6 in window7, QT APP crash

issue description:

1. version:
   OS:Win7
   QT: qt-5.6.2+VS2015
   vld: vld2.5.1
2. Code a qt widgets application demo programe, and new a memory in main function to test vld,the qt app will crash.
3. vld show the info below:
   call stack:
   d;\work\vld\src\vldallocator.h(46): Full call stack not available.

VLD performance

This ones odd, VLD performance differs dramatically between my machine and a colleague's.

Both running the same version of windows, vld (2.5.1) and MSVC 2017 (15.8.1)
My machine is a Intel i7-3840QM
Theirs is a Intel i7-4810MQ

Similar reports are listed on the old site https://archive.codeplex.com/?p=vld
"2.5.0 became much slower than 2.4.1 somehow."
"CaptureContext::IsExcludedModule takes more than 90% of execution time in allocations."

Using one comments suggestion I rebuild vld using the following
BOOL CaptureContext::IsExcludedModule() {
return g_vld.isModuleExcluded((UINT_PTR)m_context.fp);
}

Performance is now comparable and application performance with vld enabled is now about 6-7x faster.
The VirtualQuery() call in GetCallingModule() seems to be the culprit.

Anyone have any thoughts as to why?

heap errors not detected

I have included vld.h in all of my dlls and the exe, but it keeps missing some heap errors. same with _CrtSetBreakAlloc by the way.
what might be wrong? maybe it is because i use vs2017? or because i build for xp (v141_xp)?
this is the end of my output:

No memory leaks detected.
Visual Leak Detector is now exiting.
Detected memory leaks!
Dumping objects ->
{7179} normal block at 0x001BD758, 128 bytes long.
Data: 78 13 E7 05 80 13 E7 05 88 13 E7 05 90 13 E7 05
{5980} normal block at 0x00211570, 772 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{5979} normal block at 0x001C7238, 28 bytes long.
Data: <p ! > 70 15 21 00 C1 00 00 00 00 00 00 00 CD CD CD CD
Object dump complete.

Uninstalling the code does not clean up ...user.props

After trying to compile an older project from the 'net which at one point used VLD under MSVC 2015, it seems that the VLD install process modifies the MSVC property files, to force an include of vld.h but it does not remove the code when it is uninstalled.

VLD is turned off

Hi!
Maybe this question has already been asked somewhere but I didn't find it ...
I have setup everything for VLD, the paths, included it in every files, and look at vld.ini that says "
VLD = on".
But still when I launch my app in Debug mode, it says "VLD is turned off". But it still makes everything very slow, so I believe it's running. But at the end of the program, the pop-up do not show up and I have no informations.

I'm using Visual Studio 2015 on Windows 7.
Does someone knows how to activate it?

error Build system path:... visual studio 2017 UE4

Its the first time i am working with unreal on my laptop and i came across a problem in visual studio.
The intellisense is not working, it is marking all unreal stuff red but it compiles and builds. I have looked in to that problem on the unreal site of things but there is one thing that bothers me. If i right click on a include header it sais it cant find it but mentions:
" Build system path: C:\Program Files (x86)\Visual Leak Detector\include; D:\Visual Leak Detector\include "
I installed it twice to test this. But I uninstalled it again and this is still popping up.
I think it didnt uninstall correctly.
Any clues?

False positive for std::string initialized in header

Given a sample header as follows:

#pragma once

#include <string>

namespace my_string
{
    const std::string the_string("foobar");
}

VLD is detecting a leak of the allocation of the string.

It appears that the helper CallStack::isCrtStartupFunction needs to also filter out the function initterm (currently it only checks for initterm_e.

No source:line in generated reports

I installed latest vld and tried to use it in my code (which is compiled with in debug, always without "omit framepointer") No dlls are used, only single binary. FYI, dbghelp does get me source/line numbers for backtraces in my app, I use it in my code. E.g. pdb file is there and it works.
In this test run with vld.h this code wasn't used, dbghelp was loaded by vld from its own install dir.
So, I tried then to modify vld.ini to use StackWalkMethod = safe and it's been epic run, my app still didn't even reach entry point in 15 hours:

This is what fast version outputs:

WARNING: Visual Leak Detector detected memory leaks!
---------- Block 134 at 0x05840B28: 56 bytes ----------
  Leak Hash: 0x01DFF513, Count: 1, Total 56 bytes
  Call Stack (TID 16944):
    minkernel\crts\ucrt\src\appcrt\heap\malloc.cpp (21): ucrtbased.dll!malloc()
    App.UnitTest.exe!0x0221C570()
    App.UnitTest.exe!0x0221BBDB()
    App.UnitTest.exe!0x0221B650()
    App.UnitTest.exe!0x0239D9C2()
    App.UnitTest.exe!0x0239A90A()
    App.UnitTest.exe!0x00521036()
    minkernel\crts\ucrt\src\appcrt\startup\initterm.cpp (22): ucrtbased.dll!_initterm()
    App.UnitTest.exe!0x026C1C1E()

I didn't have patience to wait to complete safe version, don't know if it would produce anything useful

VLD no output when run with a mixed MFC program.

I've tried both VLD download the binaries and building from source. I can add the header file to my project and it builds and run fine but no output in the output window or in the specified file.

Failed to install 2.5.1 version on Windows7 32-bit system

Pop-up message:"Internal error: Cannot access 64-bit registry keys on this version of Windows"

False positives in MFC Application and DLLs

I am trying to use VLD with a MFC application that uses several MFC DLLs (Visual Studio 2012, MFC 11.0). I added vld.h inclusion in the stdafx.h file (in the application only) and ran the application. In the VLD report there are a lot of assumed leaks, most of them are tracked down to a constant string assignment to a CString. All of them in DLLs code. These are obviously not real leaks. The reports look like this:
MSVCR110D.dll!malloc_dbg()
mfc110ud.dll!0x000007FECE75554F()
mfc110ud.dll!0x000007FECE242211()
mfc110ud.dll!0x000007FECE2426FA()
mfc110ud.dll!0x000007FECE2427F5()
mfc110ud.dll!0x000007FECE242480()
mfc110ud.dll!0x000007FECE242CD9()
mfc110ud.dll!0x000007FECE242C3F()
mfc110ud.dll!0x000007FECE241592()
mfc110ud.dll!0x000007FECE241612()
mfc110ud.dll!0x000007FECE252BA4()
c:\ptp_ws\ptp_unit\improc_algoptp\waferbase.cpp (342): ImProc_AlgoPTP.dll!UL_ImProcAlgoPTP::CWaferBase::SetBasePrms4Wfr() + 0x1A bytes
(The last line points to our code.
I went over other similar cases and tried the advises I found - load MFC symbols, for example, and explicitly link with vld.lib. Nothing removed these reports.
Is there a way to get rid of these false positives?

Application fails to run when linked to VLD

Hi,
I'm working on the application which unfortunately have memory leaks. The application contains one executable and a couple of DLLs.
I downloaded the latest release of VLD and installed it in the default location.

Then I included the vld.h in the main executable source code and added linking to the vld.lib.

I then copied the actual DLLs from the bin/Win32 to the folder where my application is. I am working under Windows 8.1 64-bit but my application is 32-bit. Then I tried to run the application in Debug mode.

I got the following error:

The application was unable to start correctly. Click OK to close the application.

Clicking "OK" gives me following inside MSVC 2019:

Unhandled exception at 0x77CBD452 (ntdll.dll) in docview.exe: 0xC0150002: Windows was not able to process the application binding information. Please refer to your System Event Log for further information.

Trying to copy DLLs from bin\Win64 does not make any differences.

I can give you the link to the GitHub repository and instructions on how to reproduce the crash.

Or maybe I am doing something wrong?

Thank you.

Memory access violation

Dear VLD developers,

It seems I've found some rare bug. I'm not able to do pull requests, so pls review my proposition and add it if you find it ok.

Bug is in the utility.cpp in PatchImport function (line 489). After calling to ImageDirectoryEntryToDataEx the idte variable is compared to NULL (line 508). But this is not actually enough. In case idte is not null, the idte->OriginalFirstThunk must be also compared to zero. If it is 0, then the PatchImport must return immediately.

So, the line:
if (idte == NULL) {
should be replaced with:
if ((idte == NULL) || (idte->OriginalFirstThunk == 0)) {

If this is not done, then later in this function IMAGE_THUNK_DATA *thunk points to - I think - corrupted or wrong data, which in turn leads to Access memory violation in FindRealCode((LPVOID)thunk->u1.Function).

KR
Serge

Installation of vld-2.5-setup.exe on 32-bit WinXP fails

The v2.5 installer fails on 32-bit WinXP SP3 with an Internal error: Cannot access 64-bit registry keys on this version of Windows.. The v2.4rc2 installer runs without errors.

Not showing file name and line number in leak dump

I've been having this issue where VLD doesn't tell me file names and line numbers in the call stack.
main.cpp:

#include <iostream>

#include <vld.h>
/*#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>*/

#include "engine.h"
#include "levelmanager.h"
#include "opengl.h"

int main(int argc, char *argv[]) {
	if (!Engine::init(&argc, argv))
		return 1;

	int *i = new int();

	//Engine::getLevelManager()->load("Level1");

	glutMainLoop();

	Engine::shutdown();
	//_CrtDumpMemoryLeaks();

	return 0;
}

Output:

---------- Block 5 at 0x065FD190: 4 bytes ----------
  Leak Hash: 0x2CDE864B, Count: 1, Total 4 bytes
  Call Stack (TID 13128):
    ucrtbased.dll!malloc()
    GameProject.exe!0x00398C1D()
    GameProject.exe!0x0033B2D2()
    GameProject.exe!0x0039A43E()
    GameProject.exe!0x0039A2E0()
    GameProject.exe!0x0039A17D()
    GameProject.exe!0x0039A4B8()
    KERNEL32.DLL!BaseThreadInitThunk() + 0x24 bytes
    ntdll.dll!RtlGetAppContainerNamedObjectPath() + 0x137 bytes
    ntdll.dll!RtlGetAppContainerNamedObjectPath() + 0x107 bytes
  Data:
    00 00 00 00                                                  ........ ........

The main.cpp has a new int() which is never deleted, and since it's right in the main.cpp, it shouldn't be going through external dlls or some-such, and all of the memory leaks I can see show up like above.

False positive report with thread_local

Using:
Windows
Visual Studio 2019
VLD 2.5.1

When i am having thread_local variabel in a global namespace stored they are constructed on thread creation and deconstructed at thread destroy.

Apparently the VLD-thread of BOOLEAN WINAPI LdrpCallInitRoutine is also constructing these thread_local variable but not deconstructing before reporting memory leaks.

So the VLD-created thread_local variables are reported being a leak.

As workaround leaks from the same ThreadID as the VLD Thread might be filtered out.

Dosent work for me

Hi,

Visual Studio 2019 support

Never mind #58, can we get 2019 support?

How can I see the call stack including file names and line numbers ? I can only see the address of call stack.

How can I see the call stack including file names and line numbers ?
I use the vld in VS2017, but the call stack is confusing.

WARNING: Visual Leak Detector detected memory leaks!
---------- Block 1 at 0x00AB2700: 4 bytes ----------
Leak Hash: 0x19C58DBA, Count: 1, Total 4 bytes
Call Stack (TID 15860):
ucrtbased.dll!malloc()
Project1.exe!0x01231ABD()
Project1.exe!0x01231885()
Project1.exe!0x012319F3()
KERNEL32.DLL!BaseThreadInitThunk() + 0x24 bytes
ntdll.dll!RtlGetAppContainerNamedObjectPath() + 0x137 bytes
ntdll.dll!RtlGetAppContainerNamedObjectPath() + 0x107 bytes
Data:
78 56 34 12 xV4..... ........

win10,VS2017,C# call C++/CLI crash

I used vld on win10,vs2017.
I tested vld in a pure c++ project and it worked well.
Then I created a simple C++/CLI DLL project and include <vld.h> in a .cpp file,just like this:
.h:
public ref class CLIClass
{
public:
CLIClass(){}
~CLIClass(){}
static void test();
};
.cpp:
#include <vld.h>
#include "CLIClass.h"
void CLIClass::test()
{
int * a = new int;
}
Then I created a WPF application, in MainWindow_Loaded I called CLIClass.test();
I compile the project and run it, but it crashed!

I tried copy dbghelp.dll、vld_x86.dll、Microsoft.DTfW.DHL.manifest to run folder,but it still crashed...

Program s crashing with VLD

I am running Windows 8.1 with both MSVC 2010 and MSVC 2017.
My program (which has an executable binary and 10 dll) reports multiple memory leaks.

Due to the program using features of C++11 that is not available on MSVC 2010 I had to switch to 2017.

I set up VLD in the project, re-compiled, and ran the solution from inside MSVC. The program crashed with the error "wntdll.pdb failed to load"

Now when I tried to switch back to MSVC 2010, the program just crashed.

Does anybody have an idea what is happening? How I can make the VLD work?

TIA!
]