{"id":3243,"date":"2005-04-27T14:16:00","date_gmt":"2005-04-27T14:16:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/heaths\/2005\/04\/27\/getting-debug-symbols-even-for-retail-builds\/"},"modified":"2005-04-27T14:16:00","modified_gmt":"2005-04-27T14:16:00","slug":"getting-debug-symbols-even-for-retail-builds","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/setup\/getting-debug-symbols-even-for-retail-builds\/","title":{"rendered":"Getting Debug Symbols even for Retail Builds"},"content":{"rendered":"<p>Here inside Microsoft we of course have access to private debug symbols to help debug issues like I do in Windows Script as a member of the Customer Product-lifecycle Experience (<a href=\"http:\/\/blogs.msdn.com\/jledgard\/archive\/2005\/04\/01\/404879.aspx\">CPX<\/a>) team. We use a host of debugging tools like <em>Windbg.exe<\/em>, <em>ntsd.exe<\/em>, and even Visual Studio .NET. You can even <a href=\"http:\/\/www.microsoft.com\/whdc\/devtools\/debugging\/default.mspx\">download<\/a> some of these debugging tools and related documentation. The download also includes <a href=\"http:\/\/msdn.microsoft.com\/msdnmag\/issues\/03\/06\/Bugslayer\/\">Son of Strike<\/a> (SOS; <em>sos.dll<\/em>) in the <em>clr10<\/em> directory, which is featured in May&#8217;s MSDN Magazine column, <a href=\"http:\/\/msdn.microsoft.com\/msdnmag\/issues\/05\/05\/JITCompiler\/default.aspx\">JIT and Run: Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects<\/a>. Note that <em>sos.dll<\/em> can also be found in the .NET Framework 1.1 installation directory, <em>%WINDIR%\\Microsoft.NET\\Framework\\v1.1.4322<\/em>.<\/p>\n<p>To easily access the private symbols &#8211; with full source and data type information &#8211; we use a symbol server. This caches symbols for various builds of executables. You can even create your own symbol server to cache public and private symbols. Search for &#8220;symbol servers&#8221; in the bundled help files in the download above, <em>debugger.chm<\/em>.<\/p>\n<p>You can access public symbols for even retail Windows builds (and some other Microsoft applications) by setting the <font face=\"Courier New\">_NT_SYMBOL_PATH<\/font> environment variable to <font face=\"Courier New\">srv*<em>DownloadStore<\/em>*http:\/\/msdl.microsoft.com\/download\/symbols<\/font>, where <em>DownloadStore<\/em> is a download cache directory (preferrably local) where downloaded symbols are cached. Any debugger you use that makes use of the symbol server DLL like symsrv.dll &#8211; for which <font face=\"Courier New\">srv<\/font> is shorthand for <font face=\"Courier New\">symsrv*symsrv.dll<\/font> &#8211; will download symbols for the build of the module or modules you have loaded.<\/p>\n<p>This string can also be used within the debugger itself. In windbg.exe, for example, you would type the following command:<\/p>\n<pre>.sympath srv*<em>DownloadStore<\/em>*http:\/\/msdl.microsoft.com\/download\/symbols<\/pre>\n<p>In Visual Studio .NET, you can open the project properties for a Visual C++ project, select the Debugging property page, and enter the value above in the &#8220;Symbol Path&#8221; property. When you debug your project, symbols for Windows applications and libraries will be downloaded when their respective modules are loaded. No more must you work against call stacks having to resolve function addresses, but you can now see the functions for Windows executables in the call stack.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Here inside Microsoft we of course have access to private debug symbols to help debug issues like I do in Windows Script as a member of the Customer Product-lifecycle Experience (CPX) team. We use a host of debugging tools like Windbg.exe, ntsd.exe, and even Visual Studio .NET. You can even download some of these debugging [&hellip;]<\/p>\n","protected":false},"author":389,"featured_media":3843,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[14],"class_list":["post-3243","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-development"],"acf":[],"blog_post_summary":"<p>Here inside Microsoft we of course have access to private debug symbols to help debug issues like I do in Windows Script as a member of the Customer Product-lifecycle Experience (CPX) team. We use a host of debugging tools like Windbg.exe, ntsd.exe, and even Visual Studio .NET. You can even download some of these debugging [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts\/3243","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/users\/389"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/comments?post=3243"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts\/3243\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/media\/3843"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/media?parent=3243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/categories?post=3243"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/tags?post=3243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}