README.html 35 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660
  1. <?xml version="1.0" encoding="iso-8859-1"?>
  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  3. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
  4. <head>
  5. <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
  6. <style title="Visual Leak Detector" type="text/css" media="screen,print">
  7. body {
  8. margin: 0;
  9. font-family: verdana, sans-serif;
  10. }
  11. #masthead {
  12. border-width: 0 0 1px 0;
  13. border-style: solid;
  14. border-color: #808080;
  15. background-color: #3569cc;
  16. }
  17. #content {
  18. margin: 1em 1em 1em 1em;
  19. font-size: 10pt;
  20. }
  21. #toc {
  22. float: right;
  23. background-color: #ffeda5;
  24. }
  25. h1 {
  26. margin: 0 0 0 0;
  27. padding: 0.5em 1em 0 1em;
  28. text-align: right;
  29. font-size: 24pt;
  30. font-family: arial, sans-serif;
  31. color: #ffffff;
  32. }
  33. h2 {
  34. margin-top: 0;
  35. border-width: 2px;
  36. border-style: solid;
  37. border-color: #3569cc;
  38. padding-left: 1em;
  39. font-size: 16pt;
  40. font-family: trebuchet ms, sans-serif;
  41. letter-spacing: -1pt;
  42. background-color: #6599fc;
  43. }
  44. h3 {
  45. font-size: 11pt;
  46. }
  47. li {
  48. margin-bottom: 1em;
  49. }
  50. #toc h2 {
  51. margin: 0;
  52. border-width: 2px 2px 2px 0;
  53. border-style: solid;
  54. border-color: #6599fc;
  55. text-align: center;
  56. color: #ffffff;
  57. background-color: #3569cc;
  58. }
  59. #toc ul {
  60. margin-left: 0;
  61. padding: 0;
  62. list-style: none;
  63. }
  64. #toc li {
  65. margin: 1em;
  66. }
  67. a {
  68. color: #0000ff;
  69. text-decoration:none;
  70. }
  71. a:hover {
  72. text-decoration: underline;
  73. }
  74. a:visited {
  75. color: #0000ff;
  76. }
  77. .preprocessor {
  78. font-size: 10pt;
  79. font-weight: bold;
  80. }
  81. .api {
  82. font-size: 12pt;
  83. font-weight: bold;
  84. }
  85. .code {
  86. font-family: courier new, monospace;
  87. background-color: #e0e0e0;
  88. }
  89. .filename, .operator, .function {
  90. font-style: italic;
  91. }
  92. .note {
  93. margin-left: 2em;
  94. }
  95. #slogan {
  96. margin-bottom: 0;
  97. padding: 0 1em 1em 1em;
  98. border-width: 0 0 1px 0;
  99. border-style: solid;
  100. border-color: #404040;
  101. text-align: right;
  102. font-size: larger;
  103. font-style: italic;
  104. color: #6599fc;
  105. }
  106. #copyright {
  107. text-align: right;
  108. font-family: georgia, serif;
  109. color: #808080;
  110. }
  111. #compliance {
  112. text-align: right;
  113. }
  114. #compliance img {
  115. border: 0;
  116. }
  117. </style>
  118. <title>Visual Leak Detector</title>
  119. </head>
  120. <body>
  121. <div id="masthead">
  122. <h1>Visual&nbsp;Leak&nbsp;Detector&nbsp;1.0</h1>
  123. <p id="slogan">Enhanced Memory Leak Detection for Visual&nbsp;C++</p>
  124. </div> <!-- #masthead -->
  125. <div id="content">
  126. <div id="toc">
  127. <h2>Table of Contents</h2>
  128. <ul>
  129. <li><a href="#intro">Introduction</a></li>
  130. <li><a href="#use">Using Visual&nbsp;Leak&nbsp;Detector</a></li>
  131. <li><a href="#configure">Configuration Options</a></li>
  132. <li><a href="#control">Controlling Leak Detection at Runtime</a></li>
  133. <li><a href="#dlls">Detecting Leaks in DLLs</a></li>
  134. <li><a href="#build">Building Visual&nbsp;Leak&nbsp;Detector from Source</a></li>
  135. <li><a href="#x64">Windows x64 Support</a></li>
  136. <li><a href="#faq">Frequently Asked Questions</a></li>
  137. <li><a href="#restrictions">Known Restrictions</a></li>
  138. <li><a href="#license">License</a></li>
  139. <li><a href="#contact">Contacting the Author</a></li>
  140. </ul>
  141. </div> <!-- #toc -->
  142. <h2 id="intro">Introduction</h2>
  143. <p>Visual&nbsp;C++ provides built-in memory leak detection, but its capabilities are minimal at best. This memory leak detector was
  144. created as a free alternative to the built-in memory leak detector provided with Visual&nbsp;C++. Here are some of
  145. Visual&nbsp;Leak&nbsp;Detector's features, none of which exist in the built-in detector:</p>
  146. <ul>
  147. <li>Provides a complete stack trace for each leaked block, including source file and line number information when
  148. available.</li>
  149. <li>Provides complete data dumps (in hex and ASCII) of leaked blocks.</li>
  150. <li>Customizable level of detail in the memory leak report.</li>
  151. </ul>
  152. <p>Other after-market leak detectors for Visual&nbsp;C++ are already available. But most of the really popular ones, like Purify and
  153. BoundsChecker, are very expensive. A few free alternatives exist, but they're often too intrusive, restrictive, or unreliable.
  154. Here's some key advantages that Visual&nbsp;Leak&nbsp;Detector has over many other free alternatives:</p>
  155. <ul>
  156. <li>Visual&nbsp;Leak&nbsp;Detector is cleanly packaged as an easy-to-use library. You don't need to compile its source code to
  157. use it. And you only need to make minor additions to your own source code to integrate it with your program.</li>
  158. <li>In addition to providing stack traces with source files, line numbers, and function names, Visual&nbsp;Leak&nbsp;Detector
  159. also provides data dumps.</li>
  160. <li>It works with both C++ and C programs (compatible with both
  161. <span class="operator">new</span>/<span class="operator">delete</span> and
  162. <span class="function">malloc</span>/<span class="function">free</span>).</li>
  163. <li>The full source code to the library is included and it is well documented, so it is easy to customize it to suit your
  164. needs.</li>
  165. </ul>
  166. <p>Visual Leak Detector is <a href="#license">licensed</a> free of charge as a service to the Windows developer community. If you
  167. 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!",
  168. please feel free to <a href="mailto:dmoulding@gmail.com">drop me a note</a>. Or, if you'd prefer, you can
  169. <a href="#contact">contribute a small donation</a>. Both are very appreciated.</p>
  170. <h2 id="use">Using Visual&nbsp;Leak&nbsp;Detector</h2>
  171. <p>This section briefly describes the basics of using Visual&nbsp;Leak&nbsp;Detector (VLD). If your project contains DLLs that you'd
  172. like to also check for memory leaks, please see <a href="#dlls">Detecting Leaks in DLLs</a>.</p>
  173. <p>To use VLD with your project, follow these simple steps:</p>
  174. <ol>
  175. <li>Copy the VLD library (<span class="filename">*.lib</span>) files to your Visual&nbsp;C++ installation's "lib"
  176. subdirectory.</li>
  177. <li>Copy the VLD header files (<span class="filename">vld.h</span> and <span class="filename">vldapi.h</span>) to your
  178. Visual&nbsp;C++ installation's "include" subdirectory.</li>
  179. <li>In the source file containing your program's main entry point, include the <span class="filename">vld.h</span> header file.
  180. It's best, but not absolutely required, to include this header before any other header files, except for
  181. <span class="filename">stdafx.h</span>. If the source file includes <span class="filename">stdafx.h</span>, then
  182. <span class="filename">vld.h</span> should be included after it.</li>
  183. <li>If you are running Windows 2000 or earlier, then you will need to copy <span class="filename">dbghelp.dll</span> to the
  184. directory where the executable being debugged resides.</li>
  185. <li>Build the debug version of your project.</li>
  186. </ol>
  187. <p>VLD will detect memory leaks in your program whenever you run the debug version under the Visual&nbsp;C++ debugger. A report of
  188. all the memory leaks detected will be displayed in the debugger's output window when your program exits. Double-clicking on a
  189. source file's line number in the memory leak report will take you to that file and line in the editor window, allowing easy
  190. navigation of the code path leading up to the allocation that resulted in a memory leak.</p>
  191. <p class="note"><strong>Note:</strong> When you build release versions of your program, VLD will not be linked into the executable.
  192. So it is safe to leave <span class="filename">vld.h</span> included in your source files when doing release builds. Doing so will
  193. not result in any performance degradation or any other undesirable overhead.</p>
  194. <h2 id="configure">Configuration Options</h2>
  195. <p>There are a few optional preprocessor macros that you can define to control certain aspects of VLD's operation, including the
  196. level of detail provided in the memory leak report:</p>
  197. <dl>
  198. <dt class="preprocessor">VLD_AGGREGATE_DUPLICATES</dt>
  199. <dd>
  200. <p>Normally, VLD displays each individual leaked block in detail. Defining this macro will make VLD aggregate all leaks that
  201. share the same size and call stack under a single entry in the memory leak report. Only the first leaked block will be
  202. reported in detail. No other identical leaks will be displayed. Instead, a tally showing the total number of leaks matching
  203. that size and call stack will be shown. This can be useful if there are only a few sources of leaks, but those few sources
  204. are repeatedly leaking a very large number of memory blocks.</p>
  205. </dd>
  206. <dt class="preprocessor">VLD_MAX_TRACE_FRAMES</dt>
  207. <dd>
  208. <p>By default, VLD will trace the call stack for each allocated block as far back as possible. Each frame traced adds
  209. additional overhead (in both CPU time and memory usage) to your debug executable. If you'd like to limit this overhead, you
  210. can define this macro to an integer value. The stack trace will stop when it has traced this number of frames. The frame
  211. count includes the "useless" frames which, by default, are not displayed in the debugger's output window (see
  212. VLD_SHOW_USELESS_FRAMES below). Usually, there will be about five or six "useless" frames at the beginning of the call
  213. stack. Keep this in mind when using this macro, or you may not see the number of frames you expect.</p>
  214. </dd>
  215. <dt class="preprocessor">VLD_MAX_DATA_DUMP</dt>
  216. <dd>
  217. <p>Define this macro to an integer value to limit the amount of data displayed in memory block data dumps. When this number of
  218. bytes of data has been dumped, the dump will stop. This can be useful if any of the leaked blocks are very large and the
  219. debugger's output window becomes too cluttered. You can define this macro to 0 (zero) if you want to suppress data dumps
  220. altogether.</p>
  221. </dd>
  222. <dt class="preprocessor">VLD_SELF_TEST</dt>
  223. <dd>
  224. <p>VLD has the ability to check itself for memory leaks. This feature is always active. Every time you run VLD, in addition
  225. to checking your own program for memory leaks, it is also checking itself for leaks. Defining this macro forces VLD to
  226. intentionally leak a small amount of memory: a 21-byte block filled with the text "Memory Leak Self-Test". This provides
  227. a way to test VLD's ability to check itself for memory leaks and verify that this capability is working correctly.
  228. This macro is usually only useful for debugging VLD itself.</p>
  229. </dd>
  230. <dt class="preprocessor">VLD_SHOW_USELESS_FRAMES</dt>
  231. <dd>
  232. <p>By default, only "useful" frames are printed in the call stacks. Frames that are internal to the heap or VLD are not shown.
  233. Define this to force all frames of the call stacks to be printed. This macro is usually only useful for debugging VLD
  234. itself.</p>
  235. </dd>
  236. <dt class="preprocessor">VLD_START_DISABLED</dt>
  237. <dd>
  238. <p>Define this macro to disable memory leak detection initially. This can be useful if you need to be able to selectively
  239. enable memory leak detection from runtime, without needing to rebuild the executable; however, this macro should be used
  240. with caution. Any memory leaks that may occur before memory leak detection is enabled at runtime will go undetected. For
  241. example, if the constructor of some global variable allocates memory before execution reaches a subsequent call to
  242. <span class="function">VLDEnable</span>, then VLD will not be able to detect if the memory allocated by the global
  243. variable is never freed. Refer to the following section on <a href="#control">controlling leak detection at runtime</a>
  244. for details on using the runtime APIs which can be useful in conjunction with this preprocessor macro.</p>
  245. </dd>
  246. </dl>
  247. <h2 id="control">Controlling Leak Detection at Runtime</h2>
  248. <p>Using the default configuration, VLD's memory leak detection will be enabled during the entire run of your program. In certain
  249. scenarios it may be desirable to selectively disable memory leak detection in certain segments of your code. VLD provides simple
  250. APIs for controlling the state of memory leak detection at runtime. To access these APIs, include
  251. <span class="filename">vldapi.h</span> in your source file. These APIs are described here in detail:</p>
  252. <dl>
  253. <dt class="api">VLDDisable</dt>
  254. <dd>
  255. <p>This function disables memory leak detection. After calling this function, memory leak detection will remain disabled
  256. until it is explicitly re-enabled via a call to VLDEnable.</p>
  257. <p class="code">void VLDDisable (void);</p>
  258. <h3>Arguments:</h3>
  259. <p>This function accepts no arguments.</p>
  260. <h3>Return Value:</h3>
  261. <p>None (this function always succeeds).</p>
  262. <h3>Notes:</h3>
  263. <p>This function controls memory leak detection on a per-thread basis. In other words, calling this function disables
  264. memory leak detection for only the thread that called the function. Memory leak detection will remain enabled for any
  265. other threads in the same process. This insulates the programmer from having to synchronize multiple threads that
  266. disable and enable memory leak detection. However, note also that this means that in order to disable memory leak
  267. detection process-wide, this function must be called from every thread in the process.</p>
  268. </dd>
  269. <dt class="api">VLDEnable</dt>
  270. <dd>
  271. <p>This function enables memory leak detection if it was previously disabled. After calling this function, memory leak
  272. detection will remain enabled unless it is explicitly disabled again via a call to VLDDisable().</p>
  273. <p class="code">void VLDEnable (void);</p>
  274. <h3>Arguments:</h3>
  275. <p>This function accepts no arguments.</p>
  276. <h3>Return Value:</h3>
  277. <p>None (this function always succeeds).</p>
  278. <h3>Notes:</h3>
  279. <p>This function controls memory leak detection on a per-thread basis. See the remarks for
  280. <span class="function">VLDDisable</span> regarding multithreading and memory leak detection for details. Those same
  281. concepts also apply to this function.</p>
  282. </dd>
  283. </dl>
  284. <h2 id="dlls">Detecting Leaks in DLLs</h2>
  285. <p>VLD is capable of detecting memory leaks in DLLs. But DLLs can present special situations that need to be carefully considered to
  286. ensure that VLD can properly do its job. When using DLLs, you will have more than one module. Each DLL is a module and the main
  287. executable is also a module. VLD should be linked with only one module per process. So the question is: which module should VLD
  288. be linked with? The answer will depend on whether your DLLs are load-time linked or run-time linked. <em>The general rule of
  289. thumb is that VLD should always be linked with the module that is initialized first.</em></p>
  290. <h3>Load-Time Dynamic Linking</h3>
  291. <p>This is probably the most commonly used way to link with DLLs. If your program doesn't use
  292. <span class="function">LoadLibrary</span> to load your DLL, then this is the type of dynamic linking your program uses. With this
  293. form of linking, the DLL is initialized before the program's main executable. Therefore, the DLL is the first module to be
  294. initialized and VLD should be linked with the DLL. Include <span class="filename">vld.h</span> in the main source file for the
  295. DLL.</p>
  296. <p>Of course, there will most likely be several system DLLs that are loaded before any of your own DLLs. You don't need to worry
  297. about linking VLD with those DLLs, because those DLLs are not being checked for memory leaks. Only your own DLLs will be checked
  298. for leaks so VLD only needs to be linked with the first DLL <em>of your own</em> which is loaded first.</p>
  299. <p>As was mentioned earlier, you should only link VLD with <em>one</em> module. In almost all situations, linking VLD with just one
  300. module that will be loaded in a given process will enable VLD to detect memory leaks in all other modules loaded in the same
  301. process. This means that if your program links with several load-time DLLs, you only need to link with one of them -- the one
  302. that is loaded first. This rule also applies if a mix of load-time linked and run-time linked DLLs are used.</p>
  303. <p>One obvious question all of this gives rise to is: which DLL will load first and how will you know? That is a difficult question
  304. to answer. Because DLL dependencies can be circular, there is no guaranteed way to determine DLL load order. It is entirely up to
  305. the DLL loader and any seemingly innocuous change can alter the order that DLLs are loaded. But in general, DLLs that are
  306. dependencies of many other DLLs will probably be loaded sooner rather than later. If you just want to know which DLL is loaded
  307. first with your project, run it under the Visual&nbsp;C++ debugger. It will display a list of all the DLLs that are loaded and in
  308. which order. But be aware that changes to the project might unexpectedly change the DLL load order.</p>
  309. <h3>Runtime Dynamic Linking</h3>
  310. <p>You know you're using this type of dynamic linking if your program calls <span class="function">LoadLibrary</span> to load your
  311. DLL. With this type of dynamic linking, the DLL is not initialized until <span class="function">LoadLibrary</span> is called.
  312. Therefore, if all of your DLLs are runtime linked, then the main executable is the first module to be initialized and VLD should
  313. be linked with the main executable. Include <span class="filename">vld.h</span> in the main source file for the main
  314. executable.</p>
  315. <h3>Using DLLs and the Static C Runtime Libraries</h3>
  316. <p>This refers to using DLLs in conjunction with the /ML or /MT compiler options. If you do this, then there are some things you
  317. should be aware of. This creates more than one copy of the CRT in the same process. There are many things that you cannot do
  318. across CRT boundaries. For example, you can't allocate memory in one CRT instance and free it in another. This isolation of CRT
  319. instances has important ramifications for VLD. VLD can normally only monitor memory allocations from a single CRT instance. If
  320. there are two CRTs in the same process then a single instance of VLD can only detect memory leaks in one of the CRT instances
  321. (even though both exist in the same process). If you want to be able to detect memory leaks in two instances of the CRT, then
  322. you'll need two instances of VLD -- one for each CRT instance. To do this, link VLD with both the main executable (where one of
  323. the CRT instances resides) and one of the DLLs (usually all DLLs will share one instance of the CRT). The same rules from above
  324. apply when deciding which DLL to link with. The downside to this is that each instance of VLD will generate its own memory leak
  325. report.</p>
  326. <h2 id="build">Building Visual&nbsp;Leak&nbsp;Detector from Source</h2>
  327. <p>Because Visual&nbsp;Leak&nbsp;Detector is open source, the libraries can be built from source if you want to tweak them to your
  328. liking. The hardest part about building the VLD libraries from source is getting your build environment correctly set up. But if
  329. you follow these instructions carefully, the process should be fairly painless.</p>
  330. <ol>
  331. <li>VLD depends on the Debug Help library header file, <span class="filename">dbghelp.h</span>. This header file won't exist
  332. unless you have a recent Platform&nbsp;SDK installed. If you don't see <span class="filename">dbghelp.h</span> in your
  333. Platform&nbsp;SDK's "include" directory, then you probably need to
  334. <a href="http://www.microsoft.com/msdownload/platformsdk/sdkupdate/">update your Platform&nbsp;SDK</a>.</li>
  335. <li>Visual&nbsp;C++ will need to be made aware of where it can find the Debug Help library header file. If you have not done so
  336. already, add the "include" subdirectory from the Platform&nbsp;SDK installation directory to the include search path in
  337. Visual&nbsp;C++:
  338. <ul>
  339. <li><strong>Visual&nbsp;C++ 7</strong>: Go to Project Properties -> C/C++ -> General -> Additional Include Directories and
  340. add the "include" subdirectory from the Platform&nbsp;SDK. Make sure it's at the top of the list.</li>
  341. <li><strong>Visual&nbsp;C++ 6</strong>: Go to Tools -> Options -> Directories. Select "Include files" from the "Show
  342. Directories For" drop-down menu. Add the "include" subdirectory from the Platform&nbsp;SDK. Make sure it's at the top of
  343. the list.</li>
  344. </ul>
  345. </li>
  346. <li>VLD also depends on two other header files (<span class="filename">dbgint.h</span> and
  347. <span class="filename">mtdll.h</span>) that will only be installed if you elected to install the CRT source files when you
  348. installed Visual&nbsp;C++. If you didn't install the CRT sources, you'll need to re-run the Visual&nbsp;C++ installer and
  349. install them. If you are not sure whether you installed the CRT sources when you installed Visual&nbsp;C++, check to see if
  350. <span class="filename">dbgint.h</span> and <span class="filename">mtdll.h</span> exist in the "CRT\src" subdirectory of your
  351. Visual&nbsp;C++ installation directory. If those files are missing, or you don't have a "CRT\src" directory, then chances
  352. are you need to re-install Visual&nbsp;C++ with the CRT sources selected.</li>
  353. <li>Make sure that your Visual&nbsp;C++ installation's "CRT\src" subdirectory is in the include search path. Refer to step 2 for
  354. instructions on how to add directories to the include search path. The "CRT\src" subdirectory should go after the default
  355. include directory. To summarize, your include search path should look like this:
  356. <ul>
  357. <li>C:\Program&nbsp;Files\Microsoft&nbsp;Platform&nbsp;SDK\Include</li>
  358. <li>C:\Program&nbsp;Files\Microsoft&nbsp;Visual&nbsp;Studio\VCx\Include</li>
  359. <li>C:\Program&nbsp;Files\Microsoft&nbsp;Visual&nbsp;Studio\CRT\src</li>
  360. </ul>
  361. <p>In the above example, "VCx" would be "VC7" for Visual&nbsp;Studio&nbsp;.NET or "VC98" for Visual&nbsp;Studio&nbsp;6.0. Also,
  362. the name of your Platform&nbsp;SDK directory might be different from the example depending on which version of the
  363. Platform&nbsp;SDK you have installed.</p>
  364. </li>
  365. </ol>
  366. <p>Once you've completed all of the above steps, your build environment should be ready. To build VLD, just open the
  367. <span class="filename">vld.dsp</span> project and do a batch build to build all six of the configurations:</p>
  368. <ul>
  369. <li>The three debug configurations are for building versions of the library that have debugging information so that VLD itself
  370. can be conveniently debugged.</li>
  371. <li>The three release configurations build the library for use in debugging other programs.</li>
  372. <li>There are three configurations each: one for each method of linking with the C runtime library (single-threaded static,
  373. multithreaded static, and multithreaded DLL). When linking the VLD library against a program, the
  374. <span class="filename">vld.h</span> header file detects how the program is linking to the C runtime library and selects the
  375. appropriate VLD library from the three possible choices.</li>
  376. </ul>
  377. <p class="note"><strong>Note:</strong> The "release" builds of the VLD libraries are not like typical release builds. Despite the
  378. "release" name, they are actually meant to be linked only to debug builds of your own programs. When doing release builds of your
  379. programs, VLD will not be linked to them at all. In the context of VLD, "release" simply means the versions that are optimized
  380. and have the symbols stripped from them (to make the libraries smaller). They are the versions of the libraries that are included
  381. in the release of VLD itself (hence the "release" name). So when you are building the release libraries, you're really building
  382. the same libraries that are included in the main VLD distribution. The "debug" builds of VLD are strictly for debugging VLD
  383. itself (e.g. if you want to modify it or if you need to fix a bug in it).</p>
  384. <h2 id="x64">Windows x64 Support</h2>
  385. <p>The VLD source code has been modified to add support for x64-based 64-bit Windows. However, the binaries contained in the
  386. distributed versions of VLD are 32-bit only. To take advantage of the 64-bit support, you'll need to build 64-bit versions of the
  387. libraries from source. To build the 64-bit versions, follow the instructions for <a href="#build">building VLD from source</a>.
  388. So long as they are built using a x64-compatible compiler in 64-bit mode, the resulting libraries will be 64-bit libraries.</p>
  389. <p class="note"><strong>Note:</strong> I have not personally tested the 64-bit extensions so they are not absolutely guaranteed to
  390. work out-of-the-box. There may be a few lingering 64-bit compiler errors that still need to be worked out. If you need 64-bit
  391. support and run into problems trying to build the source in 64-bit mode, please
  392. <a href="mailto:dmoulding@gmail.com">let me know</a>. I'll be glad to assist in getting the 64-bit code working properly.</p>
  393. <h2 id="faq">Frequently Asked Questions</h2>
  394. <dl>
  395. <dt>When running my program with VLD linked to it I get an error message saying, "the procedure entry point SymFromAddr could
  396. not be located in the dynamic link library dbghelp.dll".</dt>
  397. <dd>
  398. <p>This typically only happens on Windows 2000. It will happen if the Debug Help Library is out-of-date. Copy the included
  399. version of <span class="filename">dbghelp.dll</span> (version 6.3) to the directory where the executable you are
  400. debugging resides. If <span class="filename">dbghelp.dll</span> is missing for some reason, you can get it by installing
  401. <a href="http://www.microsoft.com/whdc/devtools/debugging/default.mspx">Debugging Tools for Windows</a>. I recommend
  402. installing version 6.3.</p>
  403. </dd>
  404. <dt>When building VLD from source, I get the fatal error "C1189: #error : ERROR: Use of C runtime library internal header
  405. file." in either the file stdio.h or in the file assert.h (or possibly in some other standard header file).</dt>
  406. <dd>
  407. <p>Visual&nbsp;C++ is including the wrong copies of the standard headers. Be sure that the "CRT\src" subdirectory of your
  408. Visual&nbsp;C++ installation directory is listed <em>after</em> the "include" subdirectory in Visual&nbsp;C++'s include
  409. search path.</p>
  410. </dd>
  411. <dt>When building VLD from source, I get Compile Error C1083: "Cannot open include file: 'dbgint.h': No such file or
  412. directory"</dt>
  413. <dd>
  414. <p>This will happen if the CRT source files are not installed. These are an optional part of the installation when you first
  415. install Visual&nbsp;C++. Re-run the Visual&nbsp;C++ installation, if needed, to install them. If the CRT sources are
  416. already installed, make sure the "CRT\src" subdirectory of the Visual&nbsp;C++ installation directory is in
  417. Visual&nbsp;C++'s include search path.</p>
  418. </dd>
  419. <dt>Is Visual&nbsp;Leak&nbsp;Detector compatible with platforms other than Microsoft Windows?</dt>
  420. <dd>
  421. <p>No. It is designed specifically for use with Visual&nbsp;C++, and it depends on heap debugging functions found only in
  422. Microsoft's C runtime library. It's called <em>Visual</em> Leak Detector for a reason.</p>
  423. </dd>
  424. </dl>
  425. <h2 id="restrictions">Known Restrictions</h2>
  426. <p>Known restrictions in the current version of VLD, as of the time of this writing, include:</p>
  427. <ul>
  428. <li>VLD does not detect COM leaks, out-of-process resource leaks, or any other types of memory leaks that are not associated
  429. with the CRT heap. In simpler terms, VLD only detects memory leaks that are the result of calls to
  430. <span class="function">new</span> or <span class="function">malloc</span>.</li>
  431. <li>VLD is not compatible with version 6.5 of the Debug Help library (<span class="filename">dbghelp.dll</span>). The
  432. recommended version of <span class="filename">dbghelp.dll</span> to use with VLD is 6.3. Version 6.3 is included in the VLD
  433. distribution.</li>
  434. <li>The pre-compiled libraries included in the VLD distribution may not be compatible with Visual&nbsp;Studio&nbsp;2005. If you
  435. need to use VLD with Visual&nbsp;Studio&nbsp;2005, <a href="#build">building VLD from source</a> in
  436. Visual&nbsp;Studio&nbsp;2005 should create compatible libraries.</li>
  437. </ul>
  438. <h2 id="license">License</h2>
  439. <p>Visual&nbsp;Leak&nbsp;Detector is distributed under the terms of the <a href="http://www.gnu.org/copyleft/lesser.html">GNU Lesser
  440. General Public License</a>. See the <span class="filename"><a href="COPYING.txt">COPYING.txt</a></span> file for details.</p>
  441. <p>The Debug Help Library (<span class="filename">dbghelp.dll</span>) distributed with this software is not part of
  442. Visual&nbsp;Leak&nbsp;Detector and is not covered under the terms of the GNU Lesser General Public License. It is a separately
  443. copyrighted work of Microsoft Corporation. Microsoft reserves all its rights to its copyright in the Debug Help Library. Neither
  444. your use of the Visual&nbsp;Leak&nbsp;Detector software, nor your license under the GNU Lesser General Public license grant you
  445. any rights to use the Debug Help Library in <strong>ANY WAY</strong> (for example, redistributing it) that would infringe upon
  446. Microsoft Corporation's copyright in the Debug Help Library.</p>
  447. <h3>NO WARRANTY</h3>
  448. <p>BECAUSE VISUAL LEAK DETECTOR ("THE SOFTWARE") IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE SOFTWARE, TO THE EXTENT
  449. PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE
  450. SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  451. OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS
  452. WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.</p>
  453. <p>IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
  454. MODIFY AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE LICENSING TERMS SET FORTH ABOVE, BE LIABLE TO YOU FOR DAMAGES,
  455. INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE
  456. (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
  457. FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
  458. POSSIBILITY OF SUCH DAMAGES.</p>
  459. <h2 id="contact">Contacting the Author</h2>
  460. <p>Please forward any bug reports, questions, comments or suggestions to me at
  461. <a href="mailto:dmoulding@gmail.com">dmoulding@gmail.com.</a></p>
  462. <p>Donations to help support ongoing development of Visual Leak Detector are very appreciated!</p>
  463. <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
  464. <div>
  465. <input type="hidden" name="cmd" value="_s-xclick" />
  466. <input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but21.gif" name="submit" alt="Make payments with PayPal - it's fast, free and secure!" />
  467. <input type="hidden" name="encrypted" value="-----BEGIN PKCS7-----MIIHJwYJKoZIhvcNAQcEoIIHGDCCBxQCAQExggEwMIIBLAIBADCBlDCBjjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKEwtQYXlQYWwgSW5jLjETMBEGA1UECxQKbGl2ZV9jZXJ0czERMA8GA1UEAxQIbGl2ZV9hcGkxHDAaBgkqhkiG9w0BCQEWDXJlQHBheXBhbC5jb20CAQAwDQYJKoZIhvcNAQEBBQAEgYB96070OV1fBDnfqkGvVtR2bQf+WKQk1DquH9rhxL3QPke1DxmckKvbKQwjqYRjZN+FbaFky71Lz75RsdeJHKcxgcJWw6cMYOI2xrmsa4Vjp00iOPjKGpMBE7roPqnnZT7l36wBBVk7Hbnm8A3MHsqTQXN9/S/rbngN57tANCbsRTELMAkGBSsOAwIaBQAwgaQGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIfRWj6EIw0C+AgYCtBQ3JuPXxq/j/RpOCteLqJqyePyFExF3ic44Doj4py33hRo9EqJrSUTbigQVT2eHkwQWS9Exs8L9aeBQQahsZNbUCyLgqPvXOOG/Zk+5Xj/2m2oBZ5AMW8rdPVCYJ7NhAc92aiU2yObd/I8n4mLGDRf768HhASKwe/LGmZiH2bKCCA4cwggODMIIC7KADAgECAgEAMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxFDASBgNVBAoTC1BheVBhbCBJbmMuMRMwEQYDVQQLFApsaXZlX2NlcnRzMREwDwYDVQQDFAhsaXZlX2FwaTEcMBoGCSqGSIb3DQEJARYNcmVAcGF5cGFsLmNvbTAeFw0wNDAyMTMxMDEzMTVaFw0zNTAyMTMxMDEzMTVaMIGOMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxFDASBgNVBAoTC1BheVBhbCBJbmMuMRMwEQYDVQQLFApsaXZlX2NlcnRzMREwDwYDVQQDFAhsaXZlX2FwaTEcMBoGCSqGSIb3DQEJARYNcmVAcGF5cGFsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwUdO3fxEzEtcnI7ZKZL412XvZPugoni7i7D7prCe0AtaHTc97CYgm7NsAtJyxNLixmhLV8pyIEaiHXWAh8fPKW+R017+EmXrr9EaquPmsVvTywAAE1PMNOKqo2kl4Gxiz9zZqIajOm1fZGWcGS0f5JQ2kBqNbvbg2/Za+GJ/qwUCAwEAAaOB7jCB6zAdBgNVHQ4EFgQUlp98u8ZvF71ZP1LXChvsENZklGswgbsGA1UdIwSBszCBsIAUlp98u8ZvF71ZP1LXChvsENZklGuhgZSkgZEwgY4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEUMBIGA1UEChMLUGF5UGFsIEluYy4xEzARBgNVBAsUCmxpdmVfY2VydHMxETAPBgNVBAMUCGxpdmVfYXBpMRwwGgYJKoZIhvcNAQkBFg1yZUBwYXlwYWwuY29tggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAgV86VpqAWuXvX6Oro4qJ1tYVIT5DgWpE692Ag422H7yRIr/9j/iKG4Thia/Oflx4TdL+IFJBAyPK9v6zZNZtBgPBynXb048hsP16l2vi0k5Q2JKiPDsEfBhGI+HnxLXEaUWAcVfCsQFvd2A1sxRr67ip5y2wwBelUecP3AjJ+YcxggGaMIIBlgIBATCBlDCBjjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKEwtQYXlQYWwgSW5jLjETMBEGA1UECxQKbGl2ZV9jZXJ0czERMA8GA1UEAxQIbGl2ZV9hcGkxHDAaBgkqhkiG9w0BCQEWDXJlQHBheXBhbC5jb20CAQAwCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDgwMTE5NDQ0NlowIwYJKoZIhvcNAQkEMRYEFKLDwHJFsU6L329159saLBrfszYcMA0GCSqGSIb3DQEBAQUABIGAe4Mjshnc1RvJU9zF6nL8zPJ+nHO2ct1CbS1WFkQMWvh2NTwlIVSZFWSLJQZ32kNoyseoxUvE587qdBKyMOATXjchDeMr1y815+GWE6Ffqw3rWw/ytfVEtEJd4yUUq0gHqFACul4nWM5zP5A3zkLZEVN3gAmX1eLbMIcSCKuVafM=-----END PKCS7-----" />
  468. </div>
  469. </form>
  470. <p id="compliance">
  471. <a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0!" height="31" width="88" /></a>
  472. <a href="http://jigsaw.w3.org/css-validator/check/referer"><img id="valid-css" src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!" /></a>
  473. </p>
  474. <p id="copyright">Copyright &copy; 2005 Dan Moulding</p>
  475. </div> <!-- #content -->
  476. </body>
  477. </html>