I downloaded the symbols from http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspxthe package (Windows 7 RTM x86 retail symbols, all languages) but it still gives me the same error!
Done .sympath but still not working
.sympath C:inetpubwwwrootProductsServicebinProductsEntityModel.pdb;srvc:Symbolshttp://msdl.microsoft.com/download/symbols
Am I missing something? Any help will be much appreciated. Thanks
1 Answer
I would have the sympath like this
You could probably have mismatched symbols. Here is a command which will help in diagnosing the symbol load problems !sym noisy
Not the answer you're looking for? Browse other questions tagged debuggingwindbgsymbolsw3wp or ask your own question.
Asacpi.sys
The pre 2009 version of this driver is a known BSOD cause.
Please visit this link: Asus tek computer inc. -support- drivers and download p7p55d le
[URL='http://support.asus.com/download.aspx?slanguage=en&m=p7p55d%20le&p=1&s=32&os=29&hashedid=e7zic83pvqsr80lm']ASUSTeK Computer Inc. -Support- Drivers and Download P7P55D LE[/URL]
[URL='http://www.asus.com/motherboards/intel_socket_775/p5kvm/#download']ASUSTeK Computer Inc. - Motherboards- ASUS P5K-VM[/URL]
Scroll down to the utilities category, then scroll down to the 'atk0110 driver for windowsxp/vista/windows 7 32&64-bit' (it's about the 12th item down).
Download and install it.
Go to c:windowssystem32drivers to check and make sure that the asacpi.sys file is date stamped from 2009 or 2010 (not before).
Old drivers
MarvinBus64.sys 9/23/2005 4:17:03 PM fffff880`04eb5000 fffff880`04ef9000 0x00044000 0x433470cf
ASACPI.sys 10/30/2006 9:09:12 PM fffff880`02ff5000 fffff880`02ffd000 0x00008000 0x4546b048
AtiPcie.sys 11/6/2006 11:59:54 AM fffff880`01b87000 fffff880`01b8f000 0x00008000 0x454f6a0a
tifsfilt.sys 8/29/2007 7:37:29 AM fffff880`02148000 fffff880`0215f000 0x00017000 0x46d56889
timntr.sys 8/29/2007 7:38:23 AM fffff880`0190e000 fffff880`019be000 0x000b0000 0x46d568bf
PxHlpa64.sys 12/10/2007 6:49:01 PM fffff880`0113f000 fffff880`0114aae0 0x0000bae0 0x475dd06d
RtNdPt60.sys 12/10/2007 9:49:52 PM fffff880`06eaa000 fffff880`06eb6000 0x0000c000 0x475dfad0
mcdbus.sys 2/24/2009 5:34:07 AM fffff880`04e04000 fffff880`04e40880 0x0003c880 0x49a3cd1f
Plus you have Kaspersky and McAfee. Never a good idea. I would remove both and replace with Microsoft security essentials.
Kaspersky is a frequent cause of BSOD's. I would remove and replace it with Microsoft Security Essentials AT LEAST TO TEST.
http://support.kaspersky.com/downloads/utils/kavremover10.zip
http://www.microsoft.com/security_essentials/
http://download.mcafee.com/products/licensed/cust_support_patches/MCPR.exe
Symbol problems can show up in a variety of ways. Perhaps a stack trace shows incorrect information or fails to identify the names of the functions in the stack. Or perhaps a debugger command failed to understand the name of a module, function, variable, structure, or data type.
If you suspect that the debugger is not loading symbols correctly, there are several steps you can take to investigate this problem.
First, use the lm (List Loaded Modules) command to display the list of loaded modules with symbol information. The most useful form of this command is the following:
If you are using WinDbg, the Debug | Modules menu command will let you see this information as well.
Pay particular attention to any notes or abbreviations you may see in these displays. For an interpretation of these, see Symbol Status Abbreviations.
If you don't see the proper symbol files, the first thing to do is to check the symbol path:
If your symbol path is wrong, fix it. If you are using the kernel debugger make sure your local %WINDIR% is not on your symbol path.
Then reload symbols using the .reload (Reload Module) command:
If your symbol path is correct, you should activate noisy mode so you can see which symbol files dbghelp is loading. Then reload your module. See Setting Symbol Options for information about how to activate noisy mode.
Here is an example of a 'noisy' reload of the Microsoft Windows symbols:
The symbol handler first looks for an image that matches the module it is trying to load (lines three and four). The image itself is not always necessary, but if an incorrect one is present, the symbol handler will often fail. These lines show that the debugger found an image at D:MyInstallationi386ntkrnlmp.exe, but the time-date stamp didn't match. Because the time-date stamp didn't match, the search continues. Next, the debugger looks for a .dbg file and a .pdb file that match the loaded image. These are on lines 6 through 10. Line 11 indicates that even though symbols were loaded, the time-date stamp for the image did not match (that is, the symbols were wrong).
If the symbol-search encountered a catastrophic failure, you would see a message of the form:
This could be caused by items such as file system failures, network errors, and corrupt .dbg files.
Diagnosing Symbol Loading Errors
When in noisy mode, the debugger may print out error codes when it cannot load a symbol file. The error codes for .dbg files are listed in winerror.h. The .pdb error codes come from another source and the most common errors are printed in plain English text.
Some common error codes for .dbg files from winerror.h are:
0xB
ERROR_BAD_FORMAT
0x3
ERROR_PATH_NOT_FOUND
0x35
ERROR_BAD_NETPATH
It's possible that the symbol file cannot be loaded because of a networking error. If you see ERROR_BAD_FORMAT or ERROR_BAD_NETPATH and you are loading symbols from another machine on the network, try copying the symbol file to your host computer and put its path in your symbol path. Then try to reload the symbols.
Verifying Your Search Path and Symbols
Let 'c:MyDir;c:SomeDir' represent your symbol path. Where should you look for debug information?
In cases where the binary has been stripped of debug information, such as the free builds of Windows, first look for a .dbg file in the following locations:
Next, look for a .pdb file in the following locations:
Note that in the search for the .dbg file, the debugger interleaves searching through the MyDir and SomeDir directories, but in the .pdb search it does not.
Windows XP and later versions of Windows do not use any .dbg symbol files. See Symbols and Symbol Files for details.
Mismatched Builds
One of the most common problems in debugging failures on a machine that is often updated is mismatched symbols from different builds. Three common causes of this problem are: pointing at symbols for the wrong build, using a privately built binary without the corresponding symbols, and using the uniprocessor hardware abstraction level (HAL) and kernel symbols on a multiprocessor machine. The first two are simply a matter of matching your binaries and symbols; the third can be corrected by renaming your hal*.dbg and ntkrnlmp.dbg to hal.dbg and ntoskrnl.dbg.
Resolve Symbols
To find out what build of Windows is installed on the target computer, use the vertarget (Show Target Computer Version) command:
Testing the Symbols
Testing the symbols is more difficult. It involves verifying a stack trace on the debugger and seeing if the debug output is correct. Here's one example to try:
The u command unassembles the videoportfindadapter string in videoprt.sys. The symbols are correct on the debugger because common stack commands like push and mov show up on the stack. Most functions begin with an add, sub, or push operation using either the base pointer (ebp) or the stack pointer (esp).
It's usually obvious when the symbols aren't working correctly. Glintmp.sys doesn't have symbols in this example because a function isn't listed next to Glintmp:
The wrong build symbols were loaded for this stack trace. Notice how there are no functions listed for the first two calls. This stack trace looks like a problem with win32k.sys drawing rectangles:
Here's the correct stack trace. The problem is really with AGP440.sys. The first item appearing on a stack trace is usually at fault. Notice that the win32k.sys rectangle error is gone:
Useful Commands and Extensions
The following commands and extensions may be useful in tracking down symbol problems:
Deida der weg des wahren mannes pdf download. Quot;Es ist an der Zeit, sich ¨¹ber das Macho-Ideal - nur R¨¹ckgrat und kein Herz - hinauszuentwickeln,quot; schreibt David Deida. Mit klaren Hinweisen, st?rkenden Erkenntnissen, K?rper¨¹bungen und vielem mehr unterst¨¹tzt Sie der international anerkannte Experte f¨¹r Sexualit?t und Spiritualit?t, ein erf¨¹lltes Leben zu verwirklichen - jetzt sofort und ohne Kompromisse. In Der Weg des wahren Mannes untersucht David Deida die wichtigsten Themen im Leben eines Mannes - von Karriere und Familie ¨¹ber Frauen und Intimit?t zu Liebe und Spiritualit?t - um M?nnern einen praktischen Wegweiser f¨¹r ein Leben in Integrit?t, Echtheit und Freiheit zu geben.
lm (List Loaded Modules)
Lists all modules and gives the loading status of all symbols in these modules.
!dh image-header-base
Displays header information for a loaded image beginning at image-header-base.
.reload /n
Reloads all kernel symbols.
.reload [image-name]
(CDB or WinDbg only) Reloads symbols for the image image-name. If no image-name is specified, reloads symbols for all images. (It is necessary to reload symbols after the symbol path has been changed.)
!sym noisy
Turns on verbose mode for symbol loads. This can be used to get information about the module loads. See Setting Symbol Options for details.
.sympath [new-symbol-path]
Sets a new symbol path, or displays the current symbol path. See Symbol Path for details.
If the kernel symbols are correct, but you aren't getting a complete stack, the following commands may also be useful:
X *!
This will list the modules which currently have symbols loaded. This is useful if the kernel symbols are correct.
.reload /user
This will attempt to reload all user-mode symbols. This is needed while performing kernel debugging if symbols were loaded while one process was running, and a break later occurred in another process. In this case, the user-mode symbols from the new process will not be loaded unless this command is executed.
X wdmaud!*start*
This will list only the symbols in the wdmaud module whose names contain the 'start' string. This has the advantage that it forces the reloading of all the symbols in wdmaud, but only displays those with 'start' in them. (This means a shorter listing, but since there are always some symbols with 'start' in them, there will be some verification that the load has taken place.)
One other useful technique for verifying symbols is unassembling code. Most functions begin with an add, sub, or push operation using either the base pointer (ebp) or the stack pointer (esp or sp). Try unassembling (U Function) some of the functions on the stack (from offset zero) to verify the symbols.
Network and Port Problems
Problems will occur with the symbol files and while connecting to the debugger. Here are a few things to keep in mind if you encounter problems:
Determine which COM port the debug cable is connected to on the test system.
Check the boot.ini settings of the test system. Look for the /debug switch and check the baud rate and COM port settings.
Network problems can interfere with debugging if the symbols files are accessed through the network.
.dll and .sys files with the same name (for example − mga64.sys and mga64.dll) will confuse the debugger if they aren't separated into the proper directories of the symbol tree.
The kernel debugger doesn't always like replacing the build symbol files with private symbol files. Double check the symbol path and do a .reloadFileName on the misbehaving symbol. The !dlls command is sometimes useful.
Questions and Misconceptions
Q: I've successfully loaded symbols, but the stack seems to be wrong. Is the debugger broken?
A: Not necessarily. The most likely cause of your problem is that you've got incorrect symbols. Go through the steps outlined in this section to determine whether you've loaded valid symbols or not. Do not assume that because some things work you have valid symbols. For example, you very well may be able to execute dd nt!ntbuildnumber or u nt!KeInitializeProcess with incorrect symbols. Verify that they are correct using the procedures outlined above. Tomtom renault europa karte download chrome.
Q: Will the debugger still work with incorrect symbols?
A: Yes and no. Often you can get away with symbols that don't strictly match. For example, symbols from a previous Windows build will often work in certain cases, but there is no rule as to when this will work and when it will not.
Q: I'm stopped in the kernel debugger and I want to view symbols for my user-mode process. Can I do it?
A: Mostly. The support for this scenario is poor because the kernel debugger doesn't keep enough information around to track the module loads for each process, but there's a reasonable workaround. To load symbols for a user-mode module, execute a .reload -user command. This will load the user-mode modules for the current context.
Q: What does the following message mean?
*** WARNING: symbols checksum and timestamp is wrong 0x0036d6bf 0x0036ab55 for ntkrnlmp.exe
A: It means your symbols for ntkrnlmp.exe are wrong.
-->By Mark Russinovich and Ken Johnson
Published: May 16, 2017
Download LiveKd(494 KB)
Introduction
LiveKD, a utility I wrote for the CD included with Inside Windows2000, 3rd Edition, is now freely available. LiveKD allows you to runthe Kd and Windbg Microsoft kernel debuggers, which are part of theDebugging Tools for Windowspackage,locally on a live system. Execute all the debugger commands that work oncrash dump files to look deep inside the system. See the Debugging Toolsfor Windows documentation and our book for information on how to explorea system with the kernel debuggers.
While the latest versions of Windbg and Kd have a similar capability onWindows Vista and Server 2008, LiveKD enables more functionality, suchas viewing thread stacks with the !thread command, than Windbg and Kd'sown live kernel debugging facility.
Installation
First download and install the Debugging Tools for Windows package fromMicrosoft's web site:
If you install the tools to their default directory of ProgramFilesMicrosoftDebugging Tools for Windows, you can run LiveKD fromany directory; otherwise you should copy LiveKD to the directory inwhich the tools are installed.
If you haven't installed symbols for the system on which you runLiveKD, LiveKD will ask if you want it to automatically configurethe system to use Microsoft's symbol server (see the Debugging Tools forWindows documentation for information on symbol files and the Microsoftsymbol server).
NOTE: The Microsoft debugger will complain that it can't find symbolsfor LIVEKDD.SYS. This is expected, since I have not made symbols forLIVEKDD.SYS available, and does not affect the behavior of the debugger.
Using LiveKd
usage:
** liveKd [[-w]|[-k <debugger>]|[-o filename]] [-vsym][-m[flags] [[-mp process]|[pid]]][debugger options]
liveKd [[-w]|[-k <debugger>]|[-o filename]] -ml[debugger options]
liveKd [[-w]|[-k <debugger>]|[-o filename]][[-hl]|[-hv <VM name> [[-p]|[-hvd]]]] [debuggeroptions]**
Parameter | Description |
---|---|
-hv | Specifies the name or GUID of the Hyper-V VM to debug. |
-hvd | Includes hypervisor pages (Windows 8.1 and above only). |
-hvl | Lists the names and GUIDs of running Hyper-V VMs. |
-k | Specifies complete path and filename of debugger image to execute |
-m | Creates a mirror dump, which is a consistent view of kernel memory. Only kernel mode memory will be available, and this option may need significant amounts of available physical memory. A flags mask that specifies which regions to include may optionally be provided (drawn from the following table, default 0x18F8): 0001 - process private, 0002 - mapped file, 0004 - shared section, 0008 - page table pages, 0010 - paged pool, 0020 - non-paged pool, 0040 - system PTEs, 0080 - session pages, 0100 - metadata files, 0200 - AWE user pages, 0400 - driver pages, 0800 - kernel stacks, 1000 - WS metadata, 2000 - large pages The default captures most kernel memory contents and is recommended. This option may be used with -o to save faster, consistent dumps. Mirror dumps require Windows Vista or Windows Server 2008 or above. Sysinternals RamMap provides a graphical summary of the distribution of the available memory regions that can be selected for inclusion. |
-ml | Generate live dump using native support (Windows 8.1 and above only). |
-mp | Specifies a single process whose user mode memory contents should be included in a mirror dump. Only effective with the -m option. |
-o | Saves a memory.dmp to disk instead of launching the debugger. |
-p | Pauses the target Hyper-V VM while LiveKd is active (recommended for use with -o). Specifies the name or GUID of the Hyper-V VM to debug. |
-hvl | Lists the names and GUIDs of running Hyper-V VMs. |
-vsym | Displays verbose debugging information about symbol load operations. |
-w | Runs windbg instead of kd |
All other options are passed through to the debugger.
Note: Use Ctrl-Break to terminate and restart the debugger if ithangs.
By default LiveKd runs kd.exe.
Download LiveKd(494 KB)
Runs on:
- Client: Windows Vista and higher.
- Server: Windows Server 2008 and higher.
I installed retail symbols in D:Symbols and given the path to my windbg.exe but it can't be loaded why?
2 Answers
The Debug Symbols that Microsoft provides are only usable for the RTM or Sp1 Version of Windows 7. When you install an Update, the PDBs no longer match.
Here you must point to the Symbol Server to download the new PDBs:
It's easier if you have an internet connection to let windbg find and download the correct ones for you, whereby it will be cached locally:
.symfix;.reload
Will go and fetch the correct symbols from the MS symbol server at http://msdl.microsoft.com/download/symbols
if you download them yourself then you have to download the correct version matching your specific build and this is just too much of a headache to maintain so IMO it's just simpler to just let windbg handle this for you.