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.
Related
Basically, I have a Visual Studio project that builds a DLL (a VST audio plugin). Where this type of project scenario has been set up for me in the past, I would be able to build, run, and debug the plugin. Visual studio would automatically launch whichever program I was using to host the plugin. I am trying to achieve the same effect in my current project, but I don't know how to set that up. Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". The DLL still builds, and I can still run it, but I can't debug it from Visual Studio, because I don't know what I need to do in my project settings to make this happen. How can I do this?
MORE INFO:
What I do know is that, in projects where this sucessfully works, there are some modifications made to the Visual Studio project settings under fields marked 'pre-build events' and 'post-build events', so presumably what I want to do is edit these in some way to tell Visual Studio the following: "Hey, before you try and run and debug this DLL, you have to launch another program (my program is called Max.exe), and then you have to wait until that program loads the DLL. Then you can debug! Don't be a stupid computer and try to debug it before it's even loaded in Max.exe..."
What I do not know : EVERYTHING ELSE. This is literally all I know about what I'm trying to do, hense the colourful attempt to talk to a computer in English.
Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". This is unsurprising seeing as the project knows nothing about the environment I want to use to test the DLL, but the problem is that I don't have a clue what Visual Studio needs to know. I really don't know enough about programming to understand the implications of what I'm trying to do either. Yes, I did mention those fields marked pre-build and post-build because I remember them being important, but I don't know exactly what or how to write in those fields, and I also do not know if there will be more things I need to tell Visual Studio before this will work.
Q.E.D I'm not actually sure what pre and post build events are, or how they work. And I barely know the first thing about customizing VS project settings. All I know is how to write audio processing code. I felt the need for this disclaimer because typically my questions are met with angry programmers who think I don't do my own research; they fail to realize I am an audio engineer who skipped programming 101. Yes, how to debug a dll is a common question I'm sure, but answers to those questions tend to assume pre-requisite knowledge that I do not have.
You will want to edit the Command field in your project's Debugging properties. Right-click on your project in the solution explorer and click Properties (it's generally the last item). Open the Debugging page under Configuration Properties. The Command field indicates which executable to launch when debugging.
By default this contains $(TargetPath) which refers to the final binary your project compiles. This is useless for DLLs since DLLs are not executable. Change this to the path of whatever third party application you are writing a plugin for.
With this change, launching with debugging will actually launch the third party application and attach the debugger to it. Once the application loads your plugin, you will be able to debug it normally.
For Visual Studio,
In Solution Explorer, right click on project and select Properties.
In Properties, choose Configuration Properties -> Debugging.
For Command, enter the full path of the executable that will be loading your DLL. Fill in the Command Arguments and Working Directory accordingly.
In addition, you need to make sure that the executable actually loads the DLL you are building. A mistake that a lot make is to launch their executable, and not realize the executable is loading another version of the DLL they are trying to debug. This can happen due to Windows searching for the first DLL that it finds using the DLL searching logic (exe directory, path, etc.).
I've been running and compiling a program on my Windows 7 64-bit machine for several months now, but recently I had to change several VC project settings of the static libs that it uses and now the generated executable file requires me to run it in "Windows XP Compatibility Mode".
Compiled on Windows7 64-bit machine with Visual Studio 2010 SP1
The program I am generating is being built in Win32, debug mode.
The static lib projects specify Target Machine /X86.
When I run the program from the debugger, it start up and runs, however if running via the windows icon, it requires XP compatibility mode.
When trying to start outside of the debugger the EXE shows up in task manager for a second then goes away.
I've tried using Microsoft Application Verifier on it, however I don't know what to look for in the output.
I've been unable to find any details on how to troubleshoot this issue so if anyone has any ways if finding what could be causing this recent Compatibility Mode requirement I'd love to hear how it was fixed.
I have the source/projects/solutions for the majority of the static libs that I link against, as well as the exe file generated, however some of the external dependencies I only have the .lib,.dll, and .h files for. This means I can change (most) of the project settings for the dependencies if neccessary, but I need to know which ones to look for.
Thanks
To be honest, don't be afraid to make another project and copy the code files, even if it's 5 projects. You need to cut the problem in half. If it works with the new projects then it's the project files, if not, it's the code. Making projects isn't that hard really, though I'm sure a source of much consternation and something people avoid. If its the projects you can diff the files and see what happened by process of elimination. If you are really worried, copy the entire solution to another folder; always make backups.
The problem is that you probably won't be able to hoist enough information up to us to get a meaningful answer unless get lucky, and all the answers will be shots in the dark.
So I'm goign to take this question as "this happens, what can I do about it". The strategy above will get you out of it, if this used to work before. This exercise will arm you for the future and will be more productive in the long term. Go look at UAC and manifest files, aka Vista+ difference tht dramatically changes load and run behaviour (Linker Commands, Vista Migration Guide) if you need one thing to look at, but try the above process.
----
Other generic things to try:
1) another machine
2) another install of VS
3) a simple project with one window that does nothing to prove everything else in your tool chain and environment is ok.
4) planting message boxes along the code path with different messages so you know where its crapping out.
5) turing on pdb in release and runnign outside of debugger. If craps out, then try debugging and see if still craps out, but you get to see where.
6) assume that your code is unstable and you were getting lucky when it used to work. (this one is no fun). Many times things work in debug and not in release due to mem layout being different. If your progam is large you can find creative ways to use #if's whatever to elimitate code from running while haivng the whole thing still load. You can find the code that causes the bad behaviour.
7) turn off UAC and error reporting if its on, see if changes.
8) go find the "run without debugging" menu button in Visual Studio, so you don't have to go run it with the icon. That's an accident waiting to happen, and eliminates one more environmental difference. It looks like the run with debugging button, but it's hollow, a plain green triangle. It's under debug menu set. My oppinion is that it has done more harm than good to not have that on the bar by default as its confused many many people to think launching wiht VS means always using the debugger.
and so on....
When debugging a C++ Project using Visual Studio 2010, it cannot find the source for crt. When I am trying to go inside one such module, it displays "No Source Available". It also does not provide an option to Browse so that I can help it locate the source location.
Under the Option Solution->Common Properties->Debug Source Files, the proper location to the crt source is updated.
In lack of source level debugging of crt I have to read through the disassemble which is getting difficult.
Can anyone help me figure out what might be going wrong?
Please Note ** I am using an external build system via Visual Studio to build my C++ Project.
With the guidance of Hans here how I narrowed down to the problem.
While the breakpoint was still active, I listed all the Symbol Load information. I realized that msvcr100d.i386.pdb did not match the dll. It actually went all the way down to fetch from the microsoft public symbol store which off course had the symbols stripped off. So that was the root cause of my problem.
And here is a similar problem in social.msdn
You can see the cause of the problem by using Debug + Windows + Modules while you have a break active. Right-click msvcr100d.dll and select "Symbol Load Information" to get info about the .pdb that the debugger uses.
For some reason the Microsoft Symbol Server supplies one that has the source info stripped. It is probably intentional, something to do with service and security patches of the DLL getting out of sync with the source code in vc/crt/scr. You can get a real answer instead of a guess by posting to connect.microsoft.com
A workaround of sorts is to compile your code with /MTd instead of /MDd, if that's possible at all. Project + Properties, C/C++, Code Generation, Runtime Library setting. The debugger will then use the .pdb file in vc/lib. Do keep your eyes on the ball, debug your code instead of the CRT's.
You can find the sources for the CRT in your installation folder, subfolder VC\CRT\SRC.
If they're not there, did you install them when installing VS2010? (not sure whether you can really choose this).
I have built a particular dll with debug information (compiler option /Zi and linker option /DEBUG). Through an interrupt statement in the main program, I launched the Visual Studio for debugging. In the list of modules shown as seen from Debug->Windows menu, I could see that the symbols have been loaded for the dll interested in. However when I open a C++ file from that dll and try to set a breakpoint, it says debug symbols are not available for the document. There is no question that this C++ file was compiled into that dll, and that it is the same source used to build the dll (I only did it). Why does this happen? Please help, before I shoot myself.
I don't have a definitive answer, only a few suggestions.
Sometimes mdm.exe (Machine Debug Manager) stops to work properly. Terminating the process and re-starting Visual Studio helps. If the problem persists between reboots however that probably isn't the cause.
Source-file-times (last modified) that are in the future can cause all kind of weird problems. To check file times, you can do a search for nothing (Windows XP) or "*" (Windows 7). That will list all files in the selected folder. Then sort the result by date to see the max/min file time. I have no idea where the incorrect file-times come from - I just know that it happens from time to time. Might be Visual Studio itself, might be some other tool I'm using.
You could try to start the application that uses your DLL from Visual Studio, with your DLL project already open. To do that, open the "Configuration Properties", select the "Debugging" page, and enter the .exe that should be started (+ arguments if you need any). Then start the debug session as you would for a .exe project.
A cure for many problems with Visual Studio is to "clean" the project manually, and do a full re-compile. Delete all files that are generated during a build process or that store solution or project "options". i.e. all .suo .ncb .user files plus everything in the "intermediate" and "output" folders. If you're using source control, just retrieve the whole project from your source control system into a clean directory, and re-build from scratch. (Getting everything "fresh" from source control also takes care of any potential file-time problems - at least with source control systems that don't preserve file-times)
Another possible reason would be, that VS loads the wrong .pdb file. A .pdb file with a matching name could be found in a symbol server/symbol directory configured for VS (or system wide through the _NT_SYMBOL_PATH variable), or in the VS symbol cache directory. How a .pdb file with a matching name came to be in such a place is a different story, but one can easily check if the wrong .pdb file is loaded: delete the .pdb file generated by the build, and start a debug session. If VS traces "symbols loaded" for the .exe/.dll in question, it must have found a .pdb file in some other location.
Sometimes VS seems to mess up breakpoint locations in some way. I don't exactly know when or how this happens, but one of the symptoms is, that if one deletes some breakpoints, they magically reappear when starting the next debug-session. I found that setting a new breakpoint, then deleting all break points by Debug/Delete All Breakpoints, and the re-setting the required ones helps.
1) Are you not able to hit the breakpoint at all ? Generally, it gets resolved once the code in the module or stack frame needs to be hit.
2) Check if your pdb is not source information stripped
Do a Build->Clean Solution, close visual studio and then restart it and do a fresh build. This happened to me once before, and that seemed to fix it, just some outdated pdb information, I suppose.
In my case, I had renamed the C++ project. The compiler was outputting newName.lib while my other projects were still referencing oldName.lib which of course would not be removed by a Build->Clean.
I found this out by following the advice to manually clean the build directory. The subsequent linker unresolved external reference gave away the situation.
I am analyzing a .dmp file that was created and I have a call stack which gives me a lot of info. But I'd like to double click on the call stack and have it bring me to the source code.
I can right click on the call stack and select symbol settings.. where I can put the location to the PDB. But there is no option for the source code directory.
The source code directory is unfortunately hard coded into the pdb's however if you know the folders required you can use windows concept of symbolic links, junctions.
I use the tool Junction Link Magic
Read this article about how to set up a Source Server (aka SrcSrv) integration at your site.
I took the time to follow these steps for our codebase, and now we are able to take a .dmp file from any build of our software in the past 6 months... get a stack trace with symbols... and view the exact source code lines in the debugger. Since the steps are integrated into our automated builds, there's very little overhead now.
I did need to write a custom indexer for ClearCase, but they have pre-existing ones for Perforce, TFS, and maybe others.
It is worth noting that the .dmp support in VS2005 is a little shaky.. it's quite a bit more stable in VS2008.
You'll also need to configure Visual Studio to grab the symbols for the MS products from here in addition to your own symbol server:
http://msdl.microsoft.com/download/symbols
That is described in a few places such as on the Debugging Tools for Windows site.
Windbg allows you to setup source paths same as PDB's paths.
After loading the PDB, manually navigate to the source file that matches the current execution location. A PDB contains the path and filename of the source files that built its associated binary, and I suspect the debugger is smart enough to hook things up when it notices that the filename being displayed and the filename associated with with current binary location, match.