2

My pc underwent an automatic restart and when I checked event viewer, I found the bug check error. I found the location of the .dmp file created. I then downloaded WinDbg and understand the first thing I have to do is set the symbol path and then open crash dump and select the .dmp file. I found a list of the paths to use at https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-symbol-and-source-paths-in-windbg but whenever I open crash dump and click the file, it gives me the error that regarding the symbols. I've tried a lot of the paths listed, but every time I get this message repeated:

Either you specified an unqualified symbol, or your debugger * doesn't have full symbol information. Unqualified symbol resolution is turned off by default. Please either specify a fully qualified symbol module!symbolname, or enable resolution of unqualified symbols by typing ".symopt- 100". Note that enabling unqualified symbol resolution with network symbol server shares in the symbol path may cause the debugger to appear to hang for long periods of time when an incorrect symbol name is typed or the network symbol server is down. For some commands to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. * Type referenced: nt!_KPRCB

This leads me to the conclusion that I did not put the correct symbol path. I would appreciate any advice on which to choose or what else to do. I'm not using a separate system and I want to use the Microsoft server.

  • We need more information. Was this error from an application that you built yourself / have the Visual Studio PDB file and source code for? If not, you probably will not be able to use the debugger since companies usually do not distribute either of those to customers. – Dave S Jul 10 '17 at 01:43
  • The message I posted is what the windbg displays when I try to open the dmp file. It was my understanding that when my computer crashes, I can use the debugger to analyze the .dmp file to diagnose the issue which is what I was trying to do. –  Jul 10 '17 at 01:48
  • The crash dump is from whatever program (EXE) crashed. To debug that you need symbols and source for that specific program. – Dave S Jul 10 '17 at 01:54
  • I know though that after I have opened the file within the debugger, I click the "!analyze -v" hyperlink and then check the default bucket id, process name, image name, and module name which in this case are all listed as indicating wrong symbols –  Jul 10 '17 at 01:54
  • What was the program? – Dave S Jul 10 '17 at 01:55
  • @DaveS: if it was an automatic restart of the PC, it was not an executable that crashed, it was Windows itself. – Thomas Weller Jul 10 '17 at 13:24
  • Things like that are version specific. Please include more details like OS version, WinDbg version and the version of the nt module (try `lm m nt`). – Thomas Weller Jul 10 '17 at 13:31
  • Windows 10, the WinDbg should be the most recent version, downloaded it as part of the SDK from here: https://developer.microsoft.com/en-us/windows/hardware/download-windbg I also downloaded the symbols to my pc https://developer.microsoft.com/en-us/windows/hardware/download-symbols Most recent x64 version for Windows 10 –  Jul 11 '17 at 07:34

2 Answers2

2

WinDbg has a workspace concept and when you load a dump, the workspace is created for that. To avoid it asking for symbol settings every time, please do the following:

  1. Launch WinDbg
  2. Do not open any dump
  3. Go to the Symbol Settings and set a cache and server path like: srv*c:\symcache*http://msdl.microsoft.com/download/symbols WinDbg symbol path
  4. On the file menu click "Save Workspace"
  5. Close WinDbg

Next time, you do not have to set the symbol path for any dumps you open.

Nick Westgate
  • 3,088
  • 2
  • 34
  • 41
Rohith
  • 5,527
  • 3
  • 27
  • 31
1

You should make sure your have an Internet connection, then do a 

.symfix
.reload /f
!analyze -v

and check if the problems are gone. If not, it might happen that those symbols are simply not present.

If the problem is not gone, notify Andy Luhrs @aluhrs13 about the issue, make sure you include the relevant information. Potentially related: missing win32k.sys

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222