Hi, after a long time debugging my program with only asserts and dialog boxes, I finaly ran into a more deeper error. In order to debug it I downloaded "Debugging tools for Windows" so I could use WinDgb.
The problem is that I can't make WinDbg use my symbols file. The app was compiled with vc++ 2003 toolkit so it generates a vc70.pdb file for symbols.
After starting WinDbg I have to copy the image name (usualy image00400000) and rename the .pdb file to image00400000.pdb, then I reload the symbols and the only error message is "*** WARNING: Unable to verify checksum for image00400000" wich shouldn't be much trouble. By typing 'lm' I confirm that the symbols are actually loaded for my app.
The problem is that nothing changes in WinDbg (no, I'm not in ntdll), the functions in the call stack continues to be called something like 'image00400000+0x1635f' and source level debugging says there is no symbol information for it.
Has anyone ever managed to do source level debugging in WinDbg?
Can anyone help me?
Thanks in advance for the help.
User Rating: 1035 | Rate This User Report this Post to a Moderator | Link
developer Member since: 6/24/2002 From: Sweden
Posted - 9/23/2005 2:17:57 PM
> After starting WinDbg I have to copy the
> image name (usualy image00400000) and rename
> the .pdb file to image00400000.pdb
What do you mean by that. If you build hello.exe, there should also be a hello.pdb generate in the same directory. Now if you debug hello.exe from the directory you build to, it has a path to it's corresponding .pdb in it.
You shouldn't move or rename anything. Start out simple. Try making a simply project from the wizard in visual studio. First, can you debug it from visual studio and get symbols loaded? Then after that, try windbg with the same files.
User Rating: 1053 | Rate This User Report this Post to a Moderator | Link
RaptorZero Member since: 3/28/2004 From: Rio de Janeiro, Brazil
Posted - 9/23/2005 3:08:35 PM
Yes, I also found strange that I had to rename the file but that was the ony way I could get WinDbg to load those symbols.
The fact is that vc++ toolkit 2003 produces a file called vc70.pdb, the exe is called unnamedprj.exe and inside WinDbg the app apears as image00400000.
If I leave vc70.pdb as it is WinDbg says it hasn't found any symbols file, if I rename it to image00400000.pdb then WinDbg loads it ok but doesn't seems to use it.
I'll take your advice and try to debug a 'hello world', thanks.
User Rating: 1035 | Rate This User Report this Post to a Moderator | Link
developer Member since: 6/24/2002 From: Sweden
Posted - 9/23/2005 4:59:47 PM
vc70.pdb is used between the compiler and linker. It's not what you want, so just ignore it.
Verify that you have pdb generation enabled, it's on by default in debug builds, but not in release builds. For the compiler you should set "Debug Info Format to "Program Database" and for the linker you should enable "Generate Debug Info".
User Rating: 1053 | Rate This User Report this Post to a Moderator | Link
RaptorZero Member since: 3/28/2004 From: Rio de Janeiro, Brazil
Posted - 9/23/2005 5:27:01 PM
Oh, I was just setting /Zi on the compiler and I thought that would be enough. Setting the linker option /debug generates a pdb file with the same name as the exe and it works perfectly in the WinDbg.
Thanks a lot developer! You saved my life.
No symbols loaded 解决方法 收藏
How to use a symbol server with the Visual Studio .NET debugger
http://support.microsoft.com/default.aspx?scid=kb;en-us;319037
This step-by-step article describes how to use the Visual Studio .NET debugger with a symbol server to load symbols from the Microsoft Symbol Server.
Click the Play button to view this streaming media demonstration.
http://support.microsoft.com/servicedesks/ShowMeHow/319037.asx
You must have symbol information when you debug applications that may stop responding (hang or crash). Symbol files provide a footprint of the functions that are contained in executable files and dynamic-link libraries (DLLs). Additionally, symbol files can present a roadmap of the function calls that lead to the point of failure. For example, you must have the symbols when you dump call stacks inside a debugger.
For more information about a Microsoft Symbol Server that contains symbol files for Microsoft operating system components and other Microsoft products, click the following article number to view the article in the Microsoft Knowledge Base:
311503 (http://support.microsoft.com/kb/311503/ ) Use the Microsoft Symbol Server to obtain debug symbol files
Note The Microsoft Symbol Server in article 311503 has not been updated to include the symbols for the Microsoft .NET Framework. Therefore, these symbol files are not loaded. Microsoft is working to make the .NET Framework symbols available on a public symbol server.
Additionally, Microsoft Product Support Services has not tested and does not support the use of Microsoft Symbol Server with Visual Studio .NET. This article is only provided as information because of customer inquiries.
Back to the top
Update the debugging files
1. Download and then install the latest Debugging Tools for Windows kit. To download the latest Debugging Tools for Windows kit, visit the following Microsoft Web site:
http://www.microsoft.com/whdc/devtools/ddk/default.mspx (http://www.microsoft.com/whdc/devtools/ddk/default.mspx)
2. Locate the Symsrv.dll file in the /Program Files/Debugging Tools for Windows folder or the C:/WINDBG folder.
Note Because Debugging Tools may be installed in a different folder, search on your hard disk for Symsrv.dll if the file is not located in these folders.
3. Quit Visual Studio .NET if it is open.
4. Copy Symsrv.dll to the C:/Program Files/Microsoft Visual Studio .NET/Common7/IDE folder. The next time that you start Visual Studio .NET, or you start Visual Studio .NET, you can use the Symsrv.dll file to find symbol servers that you specify.
Back to the top
Specify the path to the Symbol Server
1. Start Visual Studio .NET.
2. Press CTRL+ALT+L to open the Solution Explorer window.
3. Right-click the solution, and then click Properties.
4. Expand the Common Properties and the Debug Symbol Files nodes.
5. In the Debug Symbol Files property page, type the following symbol server path:
symsrv*symsrv.dll*c:/localcache*http://msdl.microsoft.com/download/symbols
where c:/localcache is the local folder where the symbols are downloaded, and where the "http" address is the address to the Microsoft Symbol Server that contains symbols for the operating system and other Microsoft products.
Note Because the symbols are downloaded from the Internet, the Visual Studio .NET debugger may debug slowly the first time because the debugger must download all of the required symbol files.
6. On the Debug menu, point to Windows, and then click Modules to verify that symbols are loaded for a particular module while the debugger is running. The Modules window states whether the symbol information has been loaded for the module.
7. If you want to set the symbol server path for all solutions and projects, you can set a global environment variable in Control Panel. To do this, follow these steps:
1. In Control Panel, double-click System.
2. On the Advanced tab, click Environment Variables.
3. Under System Variables, click New, and then add a variable as "_NT_SYMBOL_PATH".
4. Set the value of the variable to a symbol server path, for example:
symsrv*symsrv.dll*c:/localcache*http://msdl.microsoft.com/download/symbols
Note The Visual Studio .NET debugger does not find symbols for managed components if you set the symbol server path in Solution Properties. If you have symbols for managed components, you must use the _NT_SYMBOL_PATH environment variable for the debugger to recognize symbol files of a managed component on a symbol server.
Back to the top
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Dreamcode/archive/2009/08/19/4463221.aspx
Debug->Attach to Process... Breakpoint not hit...No symbols loaded
2007年7月6日 17:12Ken Fast
0登录进行投票I have a VB .exe that calls to and external C++ .dll, which uses a C++ .lib. These were all originally developed in MSVS 6.0 and have been ported over to VS 2005 (i.e. VS 8). In VS 6.0 I used to run the VB exe program and then use Attach to Process... in order to debug the C++ side. Now when it do this my C++ breakpoints show up with the note that they cannot be hit because the symbols are not loaded. I have read lots of postings regarding this and still am in a fog.
Do all of these differenct projects (VB, C++ dll, C++ lib) need to be part of the same solution in order for this to work? In my case they are separate solutions (as they were in VS 6.0).
When I attach to process... I see the VB executable in the modules window, and it shows that the symbols for it have been loaded. What I need to do is load the symbols for my C++ code. The dll and lib do not show up in the modules list. I have added the paths to the dll and lib source code and debug build folders (PDB files) to the "Symbol Settings..." for the VB exe.
None of the ideas mentioned in other postings seem to help for my problem.
Is this not supposed to work any more in the new version of VS?
Ken
回复引用
答案
2007年7月6日 22:31John Cunningham - MSFT版主
0登录进行投票Whan attaching, you need to specify both managed and native code from the "Attach to:" "Select..." select code type dialog.
John
回复引用
2007年7月19日 13:14Ken Fast
0登录进行投票GAAAAAA! (That is my Dilbert immitation...)
I figured out the problem finally. In my project I had the output DLL generated in a different directory than the normal ./Debug/. Thinking that this might be part of the problem I moved the output back to the default location of ./Debug/ and my breakpoints showed up like they were supposed to!!!
As happy as I was that I could now hit breakpoints I still had the feeling that something was not right. I had also played around with the upper case/lower case thing with the app name and .pdb file so I did some more testing to try to figure out what was really going on. As I tried deleting my DLL file and moving it around to different locations I noticed something for the first time. In the Modules window in the debugger it actually shows the path name of the module in addition to the file name. When my DLL was not in the same directory as the PDB file the application would load an old version of the DLL from C:/Windows/System32 instead of the new version that I just built??? I didn't think there was a copy in System32 because I got an error message when I had tried to register the DLL way back when. When I deleted the old version of the DLL then I could move the new version wherever I wanted to and the Symbol Settings... functionality of VS would work correctly to locate the PDB file.
Lessons learned:
- Check the paths for files in the Modules window (Debug->Windows->Modules) and make sure your files are where you expect.
- Delete any old versions of your app or DLLs. (I know you already checked, check again...)
- Leave files in their default locations and you might have less trouble?
Ken
回复引用
全部回复
2007年7月6日 22:31John Cunningham - MSFT版主
0登录进行投票Whan attaching, you need to specify both managed and native code from the "Attach to:" "Select..." select code type dialog.
John
回复引用
2007年7月16日 20:35Ken Fast
0登录进行投票yea, did that. Still doesn't work. I had to go back and modify a number of properties settings to get VS2005 to create .pdb files. Apparently this is not a default setting, even when /DEBUG is specified. And what exactly is the point of having every project create something called "VC80.pdb" rather than defaulting to the project name or output file name? A mystery! In any case, I did all that. I now have <app_name>.pdb files at every step, and I have specified the symbol file path(s) to point to these files. I still get the same warning message, ...no symbol files... So in the "modules" window in the debugger I right click on the DLL where my breakpoint is located and click "Load Symbols" and specify the .pdb file I have now generated. I get a message back saying that the symbol file <app_name>.pdb does not match the module. Well, it was generated at the same time the module was by the same execution of the compiler/linker, so I am not sure how it does not match. I notice that the symbol file is generated in all lower case, even though my app has upper case charaters in the name. I tried changing the name of the .pdb file to match - no luck. The project properties would indicate that the .pdb file should have capitals in the name. All of the other files generated by the compiler/linker have the exact same combination of upper and lower case as the application name EXCEPT for this .pdb file. More mystery! Should I be concerned about this? I don't have then energy today to go back and change my app name to all lower case without some indication that this will do any good.
In VS6 this all worked without any effort. Why should it be so hard now?
Still without symbols,
Ken
回复引用
2007年7月19日 13:14Ken Fast
0登录进行投票GAAAAAA! (That is my Dilbert immitation...)
I figured out the problem finally. In my project I had the output DLL generated in a different directory than the normal ./Debug/. Thinking that this might be part of the problem I moved the output back to the default location of ./Debug/ and my breakpoints showed up like they were supposed to!!!
As happy as I was that I could now hit breakpoints I still had the feeling that something was not right. I had also played around with the upper case/lower case thing with the app name and .pdb file so I did some more testing to try to figure out what was really going on. As I tried deleting my DLL file and moving it around to different locations I noticed something for the first time. In the Modules window in the debugger it actually shows the path name of the module in addition to the file name. When my DLL was not in the same directory as the PDB file the application would load an old version of the DLL from C:/Windows/System32 instead of the new version that I just built??? I didn't think there was a copy in System32 because I got an error message when I had tried to register the DLL way back when. When I deleted the old version of the DLL then I could move the new version wherever I wanted to and the Symbol Settings... functionality of VS would work correctly to locate the PDB file.
Lessons learned:
- Check the paths for files in the Modules window (Debug->Windows->Modules) and make sure your files are where you expect.
- Delete any old versions of your app or DLLs. (I know you already checked, check again...)
- Leave files in their default locations and you might have less trouble?
Ken
305
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
