Quantcast
Channel: Visual Leak Detector for Visual C++ 2008-2015
Viewing all 704 articles
Browse latest View live

Edited Issue: Visual Leak Detector Crashes after loading [9099]

$
0
0
Hello,
I am new on VLD and I have started to use it (version 2.2) on Windows XP Service Pack 2.

We develop third part application to a CAD software (AutoCAD) from AutoDESK company (acad.exe built using VS2008)
It means that we create applications to customize AutoCAD and these applications are dll's loaded on AutoCAD memory space.

But, during the loading of our library, I get a crash in the application (stack overflow) and in the Visual Studio output debug I get the following information:
'acad.exe': Loaded 'C:\Data\ITLPlus\Win32\Debug\ITLPlusHDesk.arx', Symbols loaded.
'acad.exe': Loaded 'C:\Data\ITLPlus\Win32\Debug\GDCLibrary.dll', Symbols loaded.
'acad.exe': Loaded 'C:\Program Files\Visual Leak Detector\bin\Win32\vld_x86.dll', Binary was not built with debug information.
'acad.exe': Loaded 'C:\Program Files\Autodesk\AutoCAD Map 3D 2012\dbghelp.dll'
Visual Leak Detector Version 2.2 installed.
First-chance exception at 0x7c90e8ee in acad.exe: 0xC00000FD: Stack overflow.
Unhandled exception at 0x7c90e8ee in acad.exe: 0xC00000FD: Stack overflow.
First-chance exception at 0x7c90e8e5 in acad.exe: 0xC0000005: Access violation writing location 0x0f4f0ff0.
Unhandled exception at 0x7c90e8e5 in acad.exe: 0xC0000005: Access violation writing location 0x0f4f0ff0.
The program '[6020] acad.exe: Native' has exited with code 0 (0x0).

After that I have compiled VLD on Visual Studio 2008, but still the same problem.
I have debugged my application and I noticed that I get crash in the function void* vldnew (size_t size, const char *file, int line) present in vldheap.cpp.
This crash is during the call of the function RtlAllocateHeap(). (see image attached for information on the "Call Stack" windows in VStudio


Edited Issue: Visual Leak Detector Crashes after loading [9099]

$
0
0
Hello,
I am new on VLD and I have started to use it (version 2.2) on Windows XP Service Pack 2.

We develop third part application to a CAD software (AutoCAD) from AutoDESK company (acad.exe built using VS2008)
It means that we create applications to customize AutoCAD and these applications are dll's loaded on AutoCAD memory space.

But, during the loading of our library, I get a crash in the application (stack overflow) and in the Visual Studio output debug I get the following information:
```
'acad.exe': Loaded 'C:\Data\ITLPlus\Win32\Debug\ITLPlusHDesk.arx', Symbols loaded.
'acad.exe': Loaded 'C:\Data\ITLPlus\Win32\Debug\GDCLibrary.dll', Symbols loaded.
'acad.exe': Loaded 'C:\Program Files\Visual Leak Detector\bin\Win32\vld_x86.dll', Binary was not built with debug information.
'acad.exe': Loaded 'C:\Program Files\Autodesk\AutoCAD Map 3D 2012\dbghelp.dll'
Visual Leak Detector Version 2.2 installed.
First-chance exception at 0x7c90e8ee in acad.exe: 0xC00000FD: Stack overflow.
Unhandled exception at 0x7c90e8ee in acad.exe: 0xC00000FD: Stack overflow.
First-chance exception at 0x7c90e8e5 in acad.exe: 0xC0000005: Access violation writing location 0x0f4f0ff0.
Unhandled exception at 0x7c90e8e5 in acad.exe: 0xC0000005: Access violation writing location 0x0f4f0ff0.
The program '[6020] acad.exe: Native' has exited with code 0 (0x0).
```

After that I have compiled VLD on Visual Studio 2008, but still the same problem.
I have debugged my application and I noticed that I get crash in the function void* vldnew (size_t size, const char *file, int line) present in vldheap.cpp.
This crash is during the call of the function RtlAllocateHeap(). (see image attached for information on the "Call Stack" windows in VStudio

Edited Issue: Vista 64bit Pro / Visual Studio 2008 / Build Win32 : Crash and Burn [7419]

$
0
0
Try to use VLD 2.0 because I loved VLD on my 32 bit version of XP.
Finally got the code to compile and start to run, by copying VLD.dll and dbghelp.dll to the same directory as my .exe.
Right after start up .exe faults. Here is the output window in case it helps.
I am only trying to help, because I have loved using VLD in the past.

```
'NewChain.exe': Loaded 'E:\WorkProjects\HostInt\PPCNewTracking\bin\NewChain.exe', Symbols loaded.
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\user32.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\gdi32.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\secur32.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\shell32.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\shlwapi.dll'
'NewChain.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.21022.8_none_96748342450f6aa2\msvcp90d.dll', Symbols loaded.
'NewChain.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.21022.8_none_96748342450f6aa2\msvcr90d.dll', Symbols loaded.
'NewChain.exe': Loaded 'E:\WorkProjects\HostInt\PPCNewTracking\bin\vld.dll'
'NewChain.exe': Loaded 'E:\WorkProjects\HostInt\PPCNewTracking\bin\dbghelp.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\lpk.dll'
'NewChain.exe': Loaded 'C:\Windows\SysWOW64\usp10.dll'
'NewChain.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll'
First-chance exception at 0x76e60dec in NewChain.exe: 0xC0000005: Access violation.
The program '[492] NewChain.exe: Native' has exited with code 255 (0xff).
```

Edited Issue: VLD >= 2.1 Deadlocks my App [9010]

$
0
0
I'm working with multithreaded windows and it worked fine with VLD 2.0b, but with 2.1 and 2.2 it deadlocks in GetPixelFormat (Main Thread) and GetMessage (sometimes DefWindowProc) in another thread.
If you want to try it yourself, get the latest code from http://code.google.com/p/open-game-libraries/source/checkout and try running the testgloot project.

Would be very happy to see this fixed, VLD works very well otherwise.
Thanks

Commented Unassigned: Access Violation at startup [10547]

$
0
0
When launching an application using VLD, I get an access violation.
Already tried building VLD from source, and I get the same problem.
I remember happening before, and doing nothing special. Eventually started working again.
Today started crashing again, and I don't remember changing anything that could cause this.
Maybe something related to DLL loading order.

I've track down the problem to VOID VisualLeakDetector::RefreshModules(), line 1864.
It seems it tries to free resources from the old module list, when that list is null.
I could just put a check around that code and not try to do free the modules list, but probably that list shouldn't be empty at that point, and I'll be hiding the problem that causes it in the first place?

Call stack:
> vld_x64.dll!CriticalSection::Enter() Line 18 C++
vld_x64.dll!CriticalSectionLocker::CriticalSectionLocker(CriticalSection & cs) Line 54 C++
vld_x64.dll!Tree<moduleinfo_t>::begin() Line 149 C++
vld_x64.dll!Set<moduleinfo_t>::begin() Line 245 C++
vld_x64.dll!VisualLeakDetector::RefreshModules() Line 1864 C++
vld_x64.dll!VisualLeakDetector::_LdrLoadDllWin8(unsigned __int64 reserved, unsigned long * flags, unicodestring_t * modulename, void * * modulehandle) Line 1837 C++
KernelBase.dll!LoadLibraryExW() Unknown
user32.dll!_InitializeImmEntryTable() Unknown
user32.dll!_UserClientDllInitialize() Unknown
ntdll.dll!LdrpCallInitRoutine() Unknown
ntdll.dll!LdrpInitializeNode() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpPrepareModuleForExecution() Unknown
ntdll.dll!LdrGetProcedureAddressForCaller() Unknown
KernelBase.dll!GetProcAddress() Unknown
vld_x64.dll!VisualLeakDetector::_RGetProcAddress(HINSTANCE__ * module, const char * procname) Line 1790 C++
vld_x64.dll!PatchImport(HINSTANCE__ * importmodule, moduleentry_t * module) Line 479 C++
vld_x64.dll!PatchModule(HINSTANCE__ * importmodule, moduleentry_t * patchtable, unsigned int tablesize) Line 560 C++
vld_x64.dll!VisualLeakDetector::attachToLoadedModules(Set<moduleinfo_t> * newmodules) Line 624 C++
vld_x64.dll!VisualLeakDetector::VisualLeakDetector() Line 252 C++
vld_x64.dll!`dynamic initializer for 'g_vld''() Line 60 C++
vld_x64.dll!_initterm(void (void) * * pfbegin, void (void) * * pfend) Line 894 C
vld_x64.dll!_cinit(int initFloatingPrecision) Line 303 C
vld_x64.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 127 C
vld_x64.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 362 C
vld_x64.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 332 C
ntdll.dll!LdrpCallInitRoutine() Unknown
ntdll.dll!LdrpInitializeNode() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpInitializeProcess() Unknown
ntdll.dll!_LdrpInitialize() Unknown
ntdll.dll!LdrInitializeThunk() Unknown



Comments: Just an update before I go on holidays and forget this. It seems to be related to ole32.dll trying to load imm32.dll in the background, when "PatchImport" is called for "CoGetMalloc". I've worked around it by explicitly using imm32.lib in my project, and calling one of its functions (e.g: ImmIsIME(0) ), to force imm32.dll to load before vld. Couldn't spot how to fix this in vld.

Source code checked in, #5c470414d0d820112f75ecfeafb60df2ba844207

New Post: Visual Studio 2013

$
0
0
Duggernaut36 wrote:
Will you be making a v2.4 installer?
Yes, after testing
The setup\ directory uses Inno Setup 5 (which I've used before), but does not generate the same installer as v2.3. Namely, the .iss looks for the .dlls in the wrong directory and does not create the registry entries (mine had problems finding the .ini file).
Thank you, fixed
I really like that the .iss will modify the Visual Studio Win32.cpp property page to set the additional include\ & lib\ directories, though that should probably be optional.
It's already optional, you can disable it.

Source code checked in, #4c99674e651c1abb0e2786e10fbda5d4f11424d2


Commented Issue: Static CRT leaks? [10446]

$
0
0
I use Visual Studio 2012 and VLD 2.2.3.
Compile option /MTd.
Memory leak is reported with the next code.

```
int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
```

VisualLeakDetector::_HeapCreate() dose not seem to be called...

*I use machine translation, I cannot express it well.
Comments: I confirm with the 367d5721978b patch the CRT leaks are no longer improperly reported. Thank you very much!

Source code checked in, #e7cdaf5b7be8e9441954e44de39c898f9db8676c

$
0
0
Installer now update VS2008 settings

Closed Issue: Static CRT leaks? [10446]

$
0
0
I use Visual Studio 2012 and VLD 2.2.3.
Compile option /MTd.
Memory leak is reported with the next code.

```
int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
```

VisualLeakDetector::_HeapCreate() dose not seem to be called...

*I use machine translation, I cannot express it well.
Comments: Commit 367d5721978b2b67ac02947a7140daf2e8ffef72

New Post: endless recursive call to VLD itself

$
0
0
hello,

I'm using windows 8.1 enterprise edition(6.3.9600), visual studio 2008 team system sp1, static CRT lib linked to my dll.
no Application Verifier.

It can be 100% re-produced.

Updated Wiki: Using Visual Leak Detector

$
0
0

Using Visual Leak Detector


This section briefly describes the basics of using Visual Leak Detector (VLD).

Important! : Before using VLD with any Visual C++ project, you must first add the Visual Leak Detector include and library directories to the Visual C++ include and library directory search paths:
For all compiler versions take care to ensure that no junk characters get added when you add the include and library paths. If you browse to the "Program Files(x86) folder using the dialog box provided by Visual Studio and select it you could end up seeing the "%" replacing the "(".

And remember to close and open the Visual Studio IDE once you have modified the default include and library paths which the compiler and linker would always look at.
  • Visual C++ 2010/2012/2013: Go to View ->Property Manager, select Microsoft.Cpp.Win32.user. Select VC++ Directories and then "Include files" from the tree. Add the include subdirectory from the Visual Leak Detector installation directory. Move it to the bottom of the list. Then select "Library files" from the drop-down menu and add the lib\Win32 subdirectory from the Visual Leak Detector installation directory. Again, move it to the bottom of the list. Repeat for Microsoft.Cpp.x64.user, but select lib\Win64 subdirectory instead.
  • Visual C++ 2005 and 2008: Go to Tools -> Options -> Projects and Solutions -> VC++ Directories. Select "Include files" from the "Show Directories For" drop-down menu. Add the include subdirectory from the Visual Leak Detector installation directory. Move it to the bottom of the list. Then select "Library files" from the drop-down menu and add the lib\Win32 subdirectory from the Visual Leak Detector installation directory. Again, move it to the bottom of the list.
  • Visual C++ 2003: Go to Project Properties -> C/C++ -> General -> Additional Include Directories and add the include subdirectory from the Visual Leak Detector installation directory. Move it to the bottom of the list. Then select Additional Library Directories and add the lib\Win32 subdirectory from the Visual Leak Detector installation directory. Again, move it to the bottom of the list.


To use VLD with your project, follow these simple steps:
  1. In at least one C/C++ source file from your program, include the vld.h header file. It should not matter which file you add the include statement to. It also should not matter in what order the header is included in relation to other headers. The only exception is stdafx.h (or any other precompiled header). A precompiled header, such as stdafx.h, must always be the first header included in a source file, so vld.h must be included after any precompiled headers.
  2. If your program contains one or more DLLs that you would also like to check for memory leaks, then also include vld.h in at least one source file from each DLL to be included in leak detection.
  3. Build the debug version of your program.

Note: Unlike earlier (pre-1.9) versions of VLD, it is now acceptable to include vld.h in every source file, or to include it in a common header that is included by many or all source files. Only one copy of the VLD code will be loaded into the process, regardless of how many source files include vld.h.
VLD will detect memory leaks in your program whenever you run the debug version. When you run the program under the Visual C++ debugger, a report of all the memory leaks detected will be displayed in the debugger's output window when your program exits (the report can optionally be saved to a file instead, see ReportFile under Configuration Options). Double-clicking on a source file's line number in the memory leak report will take you to that file and line in the editor window, allowing easy navigation of the code path leading up to the allocation that resulted in the memory leak.

Note: When you build release versions of your program, VLD will not be linked into the executable. So it is safe to leave vld.h included in your source files when doing release builds. Doing so will not result in any performance degradation or any other undesirable overhead.

Updated Wiki: Known Restrictions

$
0
0

Known Restrictions


Known restrictions/limitations in this version of VLD include:
  • Memory allocations made through calls to functions loaded from a DLL using delayed loading may not be detected.
  • Support for programs that use MFC 7.0 or MFC 7.1 is not complete yet. Some memory leaks from such MFC-based programs may not be detected. A possible workaround for this restriction is to try forcefully including the MFC DLLs in memory leak detection, by setting the ForceIncludeModules configuration option to: "mfc70d.dll mfc71d.dll" and explicitly adding vld.lib as an input file on the linker command line (can be added through project settings by adding it to the list of library modules in the linker options). This restriction does not apply to programs that use MFC 4.2, MFC 8.0, MFC 9.0, or MFC 10.0, which are all fully supported.
  • Visual Leak Detector may report leaks internal to Visual Leak Detector if the main thread of the process terminates while other threads are still running.
  • If more than one copy of the same C Runtime DLL is loaded in the process at the same time, then some leaks may go undetected (note that loading more than one copy of the C Runtime DLL at the same time is probably a bad idea to begin with).

New Post: Visual Studio 2013

$
0
0
Unfortunately... I have no clues what can be creating the issue since the only reference to vld.lib or vld.dll are the ones that I have locally compiled... :(
There must be something bad with the scenario of only Visual Studio 2013 installed in my machine under windows 8.1

Created Unassigned: report typeid().name() memory leak when link use static CRT [10554]

$
0
0
When link use static CRT, reported typeid(..).name() in memory leak. But when link with DLL CRT, there has no memory leak report.

VS2012 UPDATE 4

Any idea?

Sample code as follow:

#include "stdafx.h"
#include <iostream>
#include <vld.h>

class Base
{
Base() {}
~Base() {}
};

int _tmain(int argc, _TCHAR* argv[])
{
std::cout << typeid(Base).name() << std::endl;

return 0;
}

Debug Output:

Visual Leak Detector Version 2.4 installed.
'TestTypeID.exe' (Win32): Loaded 'C:\Windows\SysWOW64\imm32.dll'. Cannot find or open the PDB file.
'TestTypeID.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msctf.dll'. Cannot find or open the PDB file.
WARNING: Visual Leak Detector detected memory leaks!
---------- Block 125 at 0x0061FCB8: 4272663467 bytes ----------
Call Stack:
0x7765E046 (File and line number not available): ntdll.dll!RtlAllocateHeap
f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\typname.cpp (138): TestTypeID.exe!type_info::_Name_base + 0xC bytes
f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\typinfo.cpp (28): TestTypeID.exe!type_info::name + 0xD bytes
c:\someworks\myworks\exercises\testversion\testtypeid\testtypeid.cpp (16): TestTypeID.exe!wmain + 0x14 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (241): TestTypeID.exe!__tmainCRTStartup + 0x19 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (164): TestTypeID.exe!wmainCRTStartup
0x76D7336A (File and line number not available): kernel32.dll!BaseThreadInitThunk + 0x12 bytes
0x77669F72 (File and line number not available): ntdll.dll!RtlInitializeExceptionChain + 0x63 bytes
0x77669F45 (File and line number not available): ntdll.dll!RtlInitializeExceptionChain + 0x36 bytes
Data:
CB 75 B9 39 EB 62 00 00 28 12 61 00 C8 FA 61 00 .u.9.b.. (.a...a.
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........
EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE ........ ........


Visual Leak Detector detected 1 memory leak (16925 bytes).
Largest number used: 27614 bytes.
Total allocations: 44453 bytes.
Visual Leak Detector is now exiting.

Created Unassigned: LoadLibrary bug... [10555]

$
0
0
My English is not very good.
So instead sample code.

```
#include "vld.h"
#include <Windows.h>
#include <tchar.h>
#include <process.h>

UINT WINAPI ThreadProc1(LPVOID pParam)
{
while(1)
{
HMODULE hModule = ::LoadLibrary(_T("wtsapi32.dll"));

if(NULL != hModule)
{
::FreeLibrary(hModule);
hModule = NULL;
}
}

return 0;
}

UINT WINAPI ThreadProc2(LPVOID pParam)
{
while(1)
{
HMODULE hModule = ::LoadLibrary(_T("psapi.dll"));

if(NULL != hModule)
{
::FreeLibrary(hModule);
hModule = NULL;
}
}

return 0;
}

int main(int argc, char *argv[])
{
UINT nThreadID;
HANDLE hThread[2];

hThread[0] = (HANDLE)_beginthreadex(NULL, 0, ThreadProc1, NULL, 0, &nThreadID);
hThread[1] = (HANDLE)_beginthreadex(NULL, 0, ThreadProc2, NULL, 0, &nThreadID);

::WaitForMultipleObjects(2, hThread, TRUE, INFINITE);

return 0;
}

```



=> Crash Utility.cpp

```
IMAGE_IMPORT_DESCRIPTOR* FindOriginalImportDescriptor (HMODULE importmodule, LPCSTR exportmodulename)
{
IMAGE_IMPORT_DESCRIPTOR* idte = NULL;
IMAGE_SECTION_HEADER* section = NULL;
ULONG size = 0;

// Locate the importing module's Import Directory Table (IDT) entry for the
// exporting module. The importing module actually can have several IATs --
// one for each export module that it imports something from. The IDT entry
// gives us the offset of the IAT for the module we are interested in.
g_imageLock.Enter();
__try
{
___idte = (IMAGE_IMPORT_DESCRIPTOR*)ImageDirectoryEntryToDataEx((PVOID)importmodule, TRUE,
IMAGE_DIRECTORY_ENTRY_IMPORT, &size, &section);___
}
__except(FilterFunction(GetExceptionCode()))
{
idte = NULL;
}
...
}
```

Commented Issue: Static CRT leaks? [10446]

$
0
0
I use Visual Studio 2012 and VLD 2.2.3.
Compile option /MTd.
Memory leak is reported with the next code.

```
int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
```

VisualLeakDetector::_HeapCreate() dose not seem to be called...

*I use machine translation, I cannot express it well.
Comments: Thank you skorczyl for help with bug

Commented Unassigned: LoadLibrary bug... [10555]

$
0
0
My English is not very good.
So instead sample code.

```
#include "vld.h"
#include <Windows.h>
#include <tchar.h>
#include <process.h>

UINT WINAPI ThreadProc1(LPVOID pParam)
{
while(1)
{
HMODULE hModule = ::LoadLibrary(_T("wtsapi32.dll"));

if(NULL != hModule)
{
::FreeLibrary(hModule);
hModule = NULL;
}
}

return 0;
}

UINT WINAPI ThreadProc2(LPVOID pParam)
{
while(1)
{
HMODULE hModule = ::LoadLibrary(_T("psapi.dll"));

if(NULL != hModule)
{
::FreeLibrary(hModule);
hModule = NULL;
}
}

return 0;
}

int main(int argc, char *argv[])
{
UINT nThreadID;
HANDLE hThread[2];

hThread[0] = (HANDLE)_beginthreadex(NULL, 0, ThreadProc1, NULL, 0, &nThreadID);
hThread[1] = (HANDLE)_beginthreadex(NULL, 0, ThreadProc2, NULL, 0, &nThreadID);

::WaitForMultipleObjects(2, hThread, TRUE, INFINITE);

return 0;
}

```



=> Crash Utility.cpp

```
IMAGE_IMPORT_DESCRIPTOR* FindOriginalImportDescriptor (HMODULE importmodule, LPCSTR exportmodulename)
{
IMAGE_IMPORT_DESCRIPTOR* idte = NULL;
IMAGE_SECTION_HEADER* section = NULL;
ULONG size = 0;

// Locate the importing module's Import Directory Table (IDT) entry for the
// exporting module. The importing module actually can have several IATs --
// one for each export module that it imports something from. The IDT entry
// gives us the offset of the IAT for the module we are interested in.
g_imageLock.Enter();
__try
{
___idte = (IMAGE_IMPORT_DESCRIPTOR*)ImageDirectoryEntryToDataEx((PVOID)importmodule, TRUE,
IMAGE_DIRECTORY_ENTRY_IMPORT, &size, &section);___
}
__except(FilterFunction(GetExceptionCode()))
{
idte = NULL;
}
...
}
```
Comments: Reproducible test case better than words

New Post: No Leaks Detected in CLR application (vs 2010)

$
0
0
It is easy to reproduce. Just create a new project, choose 'CLR Console Application' from the templates and add a leak, something like
#include "vld.h"

int main(array<System::String ^> ^args)
{
    int* thisShouldLeak = new int(5);
    return 0;
}
Viewing all 704 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>