[Kernel32 Dll No Matching Symbolic Information Found
Betty Neyhart
Symbol Checker (Symchk.exe) is an application that compares executable files to symbol files to verify that the matching symbols are available. Symchk may also be used to populate your symbol cache. It can read symbol information from PE files (exe, dll), dump files and processes. It also supports recursive directory search and batch files.
As you can see in the verbose mode (/v switch) you receive a lot of information about what symchk is doing. We can even read which symbols API it is using (dbghelp messages). The /os switch informs symchk to print full paths of the symbol files in the output messages. After running this command the kernel32.pdb file should be in our symbol store. If you would like to index the whole System32 directory you would like to use the /r switch which informs symchk to recursively step through the provided directory and download symbols for all the files found, eg. symchk /r /v c:\windows\system32\*.dll
With the /ip switch we can provide just process ID and symchk will download symbol files for all the modules loaded in the process. In this example we also used the /s switch which provides symchk with symbol path that it should use (overriding _NT_SYMBOL_PATH if set). In our case we were downloading symbol files from the Microsoft public server to the current directory. The listing of this directory after running this command will look as follows:
Another great functionality of symchk.exe is something called manifest files. Manifest files contain information about all symbols that must be downloaded. You may then run symchk with /om switch which will produce the manifest file without downloading any symbols. Then you can copy the manifest file to any computer that has the Internet connection and download the symbol files using /im switch. The snippet below shows an usage example:
This tool is a wrapper over the DbgHelp.dll library and uncovers almost all of its functionality. We will just look at the one usage example so if you would like to go deeper have a look at the Debugging Tools for Windows help. When you run dbh.exe with a module name as an argument it will automatically download the symbol files. So by simply calling dbh c:\windows\system32\kernel32.dll info you will download the symbol file (_NT_SYMBOL_PATH environment variable is used) and print information about it and its PE file (kernel32.dll):
You might be surprised that this tool appears here, but have you ever noticed its /PDBPATH[:VERBOSE] switch? Issuing the dumpbin /pdbpath:verbose on our kernel32.dll library will result in downloading the PDB file from the public symbol store:
This tool is quite interesting as it allows you to check which source files are indexed in the PDB file and eventually extract them. With -r switch you may check which source code paths were hardcoded in the PDB file, eg.
If you would like to have a better control over the source server stream you may check the pdbstr command. With its aid you can read and update the source server information in the PDB file. The source server stream is actually a text block with predefined sections (more info can be found here). You can dump its content by issuing:
It was literally the day after I cracked the __FILE__ determinism bug that I hit a completely different build determinism issue. I was asked to investigate why the Chrome build number reported for Chrome crashes on Windows 11 was lagging behind what was reported by winver. For example, Chrome crashes on 10.0.22000.376 were being reported as happening on 10.0.22000.318. After some code spelunking I found that crashpad retrieves the Windows version number from kernel32.dll, so I focused on that.
Aside: crashpad grabs the Windows version number from kernel32.dll instead of using GetVersionExW (which is deprecated, BTW) because the GetVersion* functions will frequently lie about the Windows version for compatibility reasons. For crash reporting we really want the actual-no-lies-we-can-handle-the-truth version number, and kernel32.dll used to be the best way to get this.
Then things got weirder. For some reason I looked at the crash dump on a different machine and the results were different. Now kernel32.dll was being reported as version .318 and .347. How can the same crash dump be reporting different version information? I was starting to feel a bit unhinged, and was starting to think I should resurrect my original plan of going to circus school.
A minidump records the minimum information needed in order to diagnose a crash. This includes the contents of the stacks from all threads, a few hundred bytes of memory from wherever registers are pointing, information about all loaded and unloaded modules, and a few other snippets. In all cases the idea is to record as little information as possible while still being able to accurately reproduce as much process state as possible. Some memory (most heap memory and global variables) are not recorded, but it is okay to have some information omitted. It is not, however, okay to have some information which is incorrect.
The minidump only records minimal information about the loaded modules, but a crash-dump analyst wants to be able to load symbols, disassemble all functions, etc., and that is where symbol servers come in. The minidump records enough information about loaded modules (a few hundred bytes) to contain the crucial identifiers which allow the debugger to download the full DLL or EXE and the PDB from the symbol servers where Microsoft and Chrome publish their DLLs, EXEs, and PDBs.
Apparently the memory saved in the minidump contains the first version number displayed by windbg for kernel32.dll, so it is consistent. But the second version number comes from the copy of kernel32.dll downloaded from the symbol server, and that was inconsistent.
So, the technical explanation is simple enough, but the design question is perplexing. It seems to me that a fundamental tenet of symbol servers is that the symbol server identifier uniquely identifies a particular file. Once you break that assumption all bets are off. I am saddened that Microsoft has decided to do this, and I hope that they fix this bug. The whole concepts of minidumps and symbol servers is on shaky ground until this is addressed.
The initial crashpad bug, wherein the wrong OS version was being reported in crashes, was fixed after some discussion with Microsoft (probably on twitter) to read the current OS version from the registry. At some point the same issue should be fixed in Chromium itself.
Here is some additional information:Using the WinDbg dialog to set symbol path, I set the path the location of
my project's .PDB file, and also to C:\Windows\Symbols, where I installed
the OS symbols I downloaded for Win Xp SP2. (My development computer does
not have Internet access, so I cannot use the on-line symbol server).When using .reload, even from a fresh compile, I get **** WARNING : Unable
to verify checksum for MyApplication.exe, and when using !sym noisy, DBGHELP
reports that my MyApplication is not source indexed.Thanks.
You email does not contain too many specifics.What module are you looking at the source for?What does the !sym noisy output show when this module is loaded?Does it say that if found symbols for the module in question?If not, then what was the output of !sym noisy? Was it a simple "file
not found"?If symbols were found for the module, what kind of symbolic information
was in the pdb? You can test the module's symbolic information from
within the debugger with the !lmi command.Since I am not personally familiar with VC6, I cannot say what the
implications are for a "Release compile". You should read the
documentation and find out. If such a compile does not produce a pdb
with type information, then you need to change your compiler options.
Source indexing is unrelated to symbols so don't worry about it..pat styles [microsoft]
> The project settings for the "Release compile" for the sample application
> that I am working with to just to get WinDbg to work 1) Turns off
> optimizations, 2) generates debug information in Microsoft format, and 3)
> produces a .PDB file located in the C:\AppDev\MyApplication\Release folder.
You need to enable debug information in both the compiler options
(/Zi) and the linker options (/DEBUG). Perhaps these were your 2)
and 3) but I'm not sure.Then, to get rid of the "Unable to verify checksum" message,
you can add /RELEASE to the linker options. VC6 does not have
a checkbox for it, so type it in. Having /RELEASE and /DEBUG
in the same command line looks a bit odd but works fine.If you intend to distribute the files built with debug symbols,
you may also want to give /OPT:REF,ICF to the linker in order to
reduce the *.EXE size. /OPT:REF is enabled by default when debug
information is not generated.
I experimented using !analyze -v when the debugger stopped at its first int
3, and pasted the verbose output at the bottom of this reply. The DBGHELP's
indicate to me that the debugger is looking in the wrong places for the Win
Xp .pdb files, which I had downloaded from Microsoft and installed to the
C:\Symbols directory. I believe that I am not telling WinDbg how to access
these files correctly, and since my develoment system is isolated from the
Internet I cannot use the Microsoft example verbatim (The Microsoft example
directs WindDbg to its online symbol server). So - I think if someone can
direct me how to access the system .pdb files (which are located in their
respective subdirectories of my local C:\Symbols directory) I will be
another step closer to getting WinDbg functional."Kalle Olavi Niemitalo" wrote in message
news:87bpz6j...@Astalo.kon.iki.fi...