"Go" match dll (EXE) and PDB methods

1. Static check
There is a tool symchk.exe in the WinDbg Debug Toolkit with a lot of options, and the following simple usage can check if a test.exe is able to find the PDB that matches it:

This is the case for success. Here's a comparison of failures:

2. If you are already inside WinDbg, you can check the following command

The last line says MATCH, certainly no problem.

3. In WinDbg (not in VS), if you are 100% sure that the source code has not changed, it has just been recompiled.
You can turn off brute force checking of GUIDs through. symopt + 40来. Thus the load is a mismatched PDB.

4. In addition to the tools mentioned in 1, there is a tool called Chkmatch,
Http://www.debuginfo.com/download/chkmatch.zip
Can be downloaded, the tool can not only check whether the match, but also the mismatch of the force to match, that is, Exe/dll and PDB in the same GUID, so in VS can be used, of course, highly dangerous, the consequences at their own risk.

5. The Hollow Circle in VS

After my colleague put that setting to a breakpoint, there was no successful setting, and the red circle was called the Hollow circle problem.

There are two possible causes for this type of problem:
(A) Indeed, the PDB does not match
(B) The time is not yet, some source files corresponding to the module itself has not been load, the corresponding PDB will not be load.
(C) The code is optimized.

In the case of (B), there is also a case where the breakpoint seems to be set wrong in WinDbg.

For a (a) or (B) judgment, in VS, you can open the Module window, which is useful for diagnosing such problems. In the Debug menu, some VS2005 after installation, in the Debug menu cannot find this menu item, do not panic, it just does not appear in the menu item, through Tools-customize can retrieve it.

In this module window, clearly list the currently debugged process, which module, each module of the PDB situation, you can also manually load a module corresponding to the symbol file, you can view the symbol file details.

In this window, one of the areas that might confuse you is: for mixed module, it will be listed two times, once for native, and once for. NET

6 With regard to (C) in 5, the code is optimized and there are several ways to respond:

(i) If you can, recompile, turn off optimization, my personal experience and habits are, never turn on optimization, unless: there is evidence that there is a performance problem somewhere, or in writing programs for RISC CPUs, the performance of such instruction sets is highly dependent on optimization.

(II) for. NET programs, you will encounter as early as possible even if the compilation optimization is turned off, still be prompted to say cannot evaluate expression, or the breakpoint is not set on the problem, this is another optimization. JIT, close it can be done by one of the less well-known ways:
If the model sentence is Test.exe
In its same directory, a Test.ini file is generated. The content is fixed as follows:

[. NET Framework Debugging Control] generatetrackinginfo=1allowoptimize=0

This disables JIT optimization, provided that the program is started the next time it takes effect.

7. Bash script (Cygwin under test) get GUID

# $1:exe/dll/pdb file# $: The target string# $#: The offset of the GUID to $function Get_guid(){exe_fname= "$"guid_mark_string=$2Guid_offset=$3Regex= "$ (echo-n $guid _mark_string | od-t x1 | sed ' s/[^/t]*/?//;s////n/g ')"Byte_offset=$ (od-v-t x1 $exe _fname | sed ' s/[^/t]*/?//;s///n/g;/^$/d ' | grep-b-P"$regex" | head-1 | Sed ' s/:.*//')od-v-T x1-j$ ((byte_offset/3+ guid_offset)) $exe _fname-n 16|head-1 | Sed ' s/[^/t]*//'}function get_guid_from_module(){Get_guid$ "RSDS" 4}function get_guid_from_pdb(){Get_guid$ "/linkinfo"-20 }

http://blackjazz07.blog.163.com/blog/static/16249081820129311077569/