Everytime I run my application, loading time is too long.
So I looked output window, this was the reason. This take too much time.
'AppName.exe': Loaded 'C:\Windows\SysWOW64\mswsock.dll', Cannot find or open the PDB file
I'm using VisualStudio 2010 rightnow, but it was ok with VisualStudio 2005.
64bit, 32bit doesn't matter. I tested on both system, all slow.
Can anyone give me any idea?
Sounds like you are running your program under the Visual Studio debugger and you have the debugger set to automatically (try to) load debug symbols from Microsoft's symbol server.
When symbols for a DLL cannot be found locally or on the symbol server there is a long delay while Visual Studio works it out. Who knows why it takes so long, and why VS does not cache the fact there is no symbol available (to at least avoid checking every single time), but that's how it is.
Still, debug symbols are very useful and available for most system DLLs. Rather than turn off the symbol server completely, I find it best to make it only load symbols on demand. That way when you need them for a module you can right-click it (e.g. in a stack trace window) and tell VS to find the symbols for it.
You can do this under Tools -> Options -> Debugging -> Symbols by changing Automatically load symbols for to Only specified modules. (For modules you want the symbols to often, you can add them to the list so you don't have to keep manually pulling them in.)
Sounds like you've got a slow or malfunctioning Internet connection. Tools + Options, Debugging, Symbols, untick "Microsoft Symbol Servers".
Related
I'm currently working on a tool that allows me to change C++-code on the fly. Changed files are compiled in the background, loaded from the .obj, relocated & linked, and patched into the running process.
This works fine so far.
However, I have been unable to load symbols for the new functions so that they are visible by the debugger. I have tried creating a virtual module using SymLoadModuleEx and adding symbols via SymAddSymbol, but that didn't work.
Ultimately, I would like to be able to add symbols and line information for the new functions. I could do that from either a .pdb file or the COFF info stored in the .obj (I have both), but I seem to be missing the crucial part that informs the debugger.
Is there a function for this that I simply missed? Or an undocumented code for RaiseException that is understood by the debugger (similar to naming a thread)?
I use Visual Studio, but any help in getting this to work in either the VS debugger or WinDBG is greatly appreciated.
I have a very frustrating problem, I'm debugging my code, and for complete Call Stack I need to get symbols for msvcr120.dll (msvcr120.i386.pdb).
The thing is, that I can't get it.
tried loading it from MS Symbols Servers, result:
SYMSRV: http://msdl.microsoft.com/download/symbols/msvcr120.i386.pdb/16F5E2EF340A453ABC8B8F67DC6FD8082/msvcr120.i386.pdb not found
http://msdl.microsoft.com/download/symbols: Symbols not found on symbol server.
tried downloading manualy symbols packages for various Windows versions from MS, downloaded aprox. 2GB, got symbols for msvcr from 90 to 110, and two 120 (from Win 10 package):
msvcr120.i386.coresys.pdb
msvcr120_clr0400.i386.pdb
So, is there a way to get "msvcr120.i386.pdb" ?
In order to get the proper PDB for the file, you need to know which module is actually loaded. If you create a crashdump (.DMP) of the program while running (which you can do with taskmanager), it should show you the exact file loaded, including it's full path. You can also use a tool like dependency walker, which may do a better job at finding the full path.
Once you have the path, you can then specifically try to force-load symbols for that module by right-clicking, loading, and pointing to the exact file in question. That should get the proper hash and load the correct PDB from the MS symbol store into your local cache.
What's likely happening is that the program you're running either has a manifest calling out a specific SxS version of the DLL, OR your program has crashed enough that Windows has placed it in "compatibility mode". Either way, that means the program and VS are finding different versions of the DLL, thus the problem you're having. You can also see this when your program crashes on a different machine than the one you're debugging on, especially if they're not both exactly in the same place for windows updates.
If you do dev work regularly, you should disable Windows automatically putting things into compatibility mode. It will save you lots of headaches down the road.
I have set up a symbol server in VS 2010 according to this:
http://msdn.microsoft.com/en-us/library/vstudio/b8ttk8zy(v=vs.100).aspx
But my goal is to step into the Regex class in the RegularExpressions namespace:
Imports System.Text.RegularExpressions
Module Module1
Sub Main()
Dim matObject As Match = Regex.Match("abc", "a")
End Sub
End Module
I do know that the RegularExpressions symbols in the System.dll Assembly were made public a long time ago because I read an article on it a while back that was excited about it and did a small overview. But I can't find the article.
As it stands, when I "Step Into" my Match function, it doesn't even give me the Step-Over dialog. It just steps over.
Turns out there are multiple issues surrounding this. Part of them include Visual Studio 2008 SP1, but that is hardly a relevant issue in late 2013.
The solution for me was... Don't use a Symbol Server. At least in VS 2010, it forces you to use the "Microsoft Symbol Servers" which, depending on one or two factors, may load from the generic location, or may load from http://referencesource.microsoft.com/symbols.
The problem with both, is that every time I've used those Symbol File Locations, they are stripped PDB's. Though as you might notice in the Subdomain "http://referencesource.microsoft.com/symbols", Reference Source is getting a big closer.
So what I did was navigate to: Download Source, which is at that same subdomain. Since I'm using .NET 4.0, I Downloaded the .NET 4.0 Source Files.
WTF?? So now I have downloaded some junk file named NetFramework.aspx. It just freezes my computer when I open it. What's the point? Well, nobody tells you this, but you have to re-name it to Whatever.msi. It's actually an installer.
Once you run the installer, you have the full symbols somewhere on your machine. YAY AGAIN!!! At that point, you need to make sure your Visual Studio is set up properly.
Make sure your project Framework matches the Framework of your Source you just downloaded. (And/Or Vice Versa)
Make sure "Enable .NET Framework Source Stepping" is enabled.
For me, in my Options > Debugging > Symbols menu, I selected "Only Specified Modules" and I selected nothing there. Also, I un-checked the PDB Locations so nothing was selected.
Sometimes the Platform Target is an issue. Mine is set to AnyCPU, but you may need to experiment?
OKAY!! All set, let's do this... Fail.
Now when you hit F11, it still just steps over the code. Well, if you look at your Modules (While running), HOPEFULLY the symbols for System or mscorlib or whatever your Assembly is says SYMBOLS NOT LOADED. (That's Good).
Why is that good? Because if they're loaded, you can't load them. And typically, if they're loaded, they are loaded from some janky stripped PDB location that gets you nowhere. So you right-click the assembly of choice and Load From Path... and go to wherever you installed those PDBs from the MSI.
Well great... now if you try to step into the .NET Framework code, or if you try to Load the code from the Call-Stack, you just get a missing code error and the option to find the source code is Greyed Out!! Well I thought we HAD The CODE!!!! I JUST LOADED IT.
Let's look back at the Module window. Next to the assembly you're wanting to load, you'll probably notice in the Version that it says something like "built by: RTMGDR" or "RTMRel" or something like that. Well, RTMGDR means the current version of code being used is different from the original. Why is it different? Because a KB Security Update was installed. And since the Code is different from the PDB... you can't step in.
Unfortunately, you can't get the latest PDB. Who knows why... maybe because it's a security update. But what you CAN do... is google your version like so:
"mscorlib.dll" 4.0.30319.xxx site:support.microsoft.com/kb
You do not have to click anything. Just look at the URL of the first result and you'll see the KB number like so:
support.microsoft.com/kb/12345
Open up your Add/Remove programs (Run: appwiz.cpl), and view Installed Updates. You'll VERY Easily find that KB under your Visual Studio group, and can Uninstall it.
Then run Visual Studio again.. and you'll probably see a new RTMGDR with an Older version... Google that, Remove it's KB... Rinse and Repeat.
KEEP TRACK OF THE KB's YOU REMOVE (In Order). So you can later Re-Install them after your Research.
Once you are FINALLY down to Version x.x.xxxx.1 (RTMRel), you run your Visual Studio to the break point... Open your Modules... Load Symbols From Path... Select your PDB's from your MSI... Then.... Step into your .NET Code
FINALLY!!!
Now when you're done, re-install those KB's, but keep all other settings the same for next time. Security is important.
Got this callstack when I open a Windows crash dump in Visual Studio 2005:
> myprog.exe!app_crash::CommonUnhandledExceptionFilter(_EXCEPTION_POINTERS * pExceptionInfo=0x0ef4f318) Line 41 C++
pdm.dll!513fb8e2()
[Frames below may be incorrect and/or missing, no symbols loaded for pdm.dll]
kernel32.dll!_UnhandledExceptionFilter#4() + 0x1c7 bytes
...
Looking at the module load info:
...
'DumpFM-V235_76_1_0-20110412-153403-3612-484.dmp': Loaded '*C:\Program Files\Common Files\Microsoft Shared\VS7Debug\pdm.dll', No matching binary found.
...
We see that this binary was not even loaded, because the machine used to analyze the dump is a different machine than the machine that produced the dump.
I don't have access to this other machine at the moment -- can I somehow get this stack fixed, or will I always need the exact binary at this exact path location?
If you absolutely want to debug this dump in Visual Studio, then you can get away with copying the system DLLs from the machine that produced the dump to the same folder where your .dmp file is. That way, it will load those binaries instead of trying to find them in the same path on the debugging system as they were on the original system (which probably will contain different versions of the same modules).
As Naveen pointer out though, you won't have this problem when loading the dump in WinDBG (for reasons I have yet to understand). That is why when I get a dump from clients, I always analyze them in WinDBG.
If you need help on using WinDBG for crash dump analysis, the following Web site is full of info on the subject: http://www.dumpanalysis.org/.
Another option is to use the ModuleRescue tool from the folks at DebugInfo.com. This will scan a dump file, allow you to choose the module that isn't loading symbols, and then it generates a fake module that has just enough info in it for the debugger to load the symbols from the symbol server.
When Visual Studio can't load the symbols for this module and opens a dialog asking you to find the symbols, just point your debugger at that fake module and it will load correctly.
This tool basically does the same thing that WinDbg does, albeit with a different workflow.
In a way following on from reading a windows *.dmp file
Having received a dump file from random customer, running the debug session to see the crash, you often find it is in a MS or other third party library. The next issue is that you may not have knowledge of the PC setup to such an extent that you can ensure you have the actually modules available.
For instance I'm currently stuck trying to get symbols to load for ntdll.dll (5.01.2600.5512). In MSVC 2005 the path column in the modules list window shows a * before the fully pathed file name, and refuses to load symbols I have downloaded for XP/SP1/SP1a/SP2/SP3.
I have the symbol server setup to download from the internet and store in a local cache which seems to have been working fine for modules that I do have on my PC.
Using GUI equivelant to the method
Set _NT_SYMBOL_PATH=srv*d:\SymbolCache*\\server1\Third-Party-PDB;srv*d:\SymbolCache*\\server2\Windows\Symbols*http://msdl.microsoft.com/download/symbols
Perhaps I have the wrong symbols, but as new ones are not downloading where do I go to next? Do I have to contact the customer and ask what SP they have installed, and any other patches? Do I have to install that machine and then run up the debugger with the dmp file to get the symbols I need?
If you are using WinDbg (part of the Debugging Tools for Windows package), then it's simple to have it pull the right symbols for you from Microsoft automatically. Configure the symbol path using the ".symfix" (or ".symfix+", to simply append to your existing symbol search path) command.
Once you have that done and you have the crash dump loaded in WinDbg, type ".reload /f" to cause WinDbg to reload the symbols. It will use the information within the dump file itself to pull the correct symbols from Microsoft's public symbol server, regardless of what DLLs you have on your machine.
If for some reason the symbols aren't loading properly after you have done this, enter "!sym noisy" into WinDbg's command window and reload the symbols again. As WinDbg attempts to load them, you will see it output any errors that it encounters in its search/load process. These error messages will help you further diagnose what is going wrong and why the correct symbols aren't being loaded.
This post has information that may also be of use.
If you're typing "Set _NT_SYMBOL_PATH = srv..." into a command prompt, there are two things to consider:
cmd.exe's set command does not ignore whitespace, so this defines a variable called "_NT_SYMBOL_PATH", not "_NT_SYMBOL_PATH".
You must start the debugger as a child of that command prompt. However, you don't have to do this if you use the Control Panel to set persistent environment variables, or if you use the setx command (in Windows Vista or one of the Windows Resource Kits).
If you're setting the symbol path some other way, then this doesn't apply.
What are you using to debug the minidump? I.e., WinDBG or Visual Studio? And how was the minidump generated?
There should be enough information in the minidump to resolve system dll symbols correctly. Are you using a local download of symbols or http://msdl.microsoft.com/?
Update: You should be able to add the public microsoft symbol store to Tools->Options->Debugging->Symbols->Symbol file (.pdb) locations, and then manually load the symbols by right clicking on the module in the Modules window and loading them if it isn't done automatically.
It's also possibly (likely) that VS 2005 doesn't look at _NT_SYMBOL_PATH to resolve minidump symbols.
Try following the instructions at this kb article, and make sure your symbol path is configured correctly, that WinDbg has access to it, and that the ntdll symbols (for example) are actually downloaded to your symbol cache. The article also provides instructions on how to manually download and verify symbols in you cache via the SymChk tool.