I am trying to debug a small application that deliberately throws an exception in a dependent library. I built the code for both, but I am debugging on a workstation that I did not use to build the dependent library. I have a step in my small build process to Index Sources and Publish Symbols (using the vNext build system) for the dependent library.
I want to be able to debug and step into the code of the dependent library. My expectation is that the indexing information stamped into the pdb file will allow the acquisition of the source code files "on the fly".
The pdb file successfully uploads to the source server during the vNext build, and the pdb file is successfully loaded from the symbol cache directory I've specified in visual studio according to Debug -> Windows -> Modules.
My application throws an exception deliberately so the debugger will have something to break into. When it does, I see the code that is throwing in the stack trace, so I know the symbols are loading correctly. When I double click on that entry in the stack trace, I am not taken to the source.
Due to the indexing information, I would have expected Visual Studio to get the source, but I am shown a file browse dialog. Note, I am using Visual Studio 2017.
Here is the indexing information in the pdb file (which shows the pdb was indexed correctly):
------------------------------------------------
VERSION=3
INDEXVERSION=2
VERCTRL=Team Foundation Server
DATETIME=Thu Mar 08 15:58:40 2018
INDEXER=TFSTB
SRCSRV: variables ------------------------------------------
TFS_EXTRACT_CMD=tf.exe view /version:%var4% /noprompt "$%var3%" /server:%fnvar%(%var2%) /console > %SRCSRVTRG%
TFS_EXTRACT_TARGET=%targ%\%var2%%fnbksl%(%var3%)\%var4%\%fnfile%(%var5%)
SRCSRVVERCTRL=tfs
SRCSRVERRDESC=access
SRCSRVERRVAR=var2
VSTFSSERVER=REDACTED
SRCSRVTRG=%TFS_EXTRACT_TARGET%
SRCSRVCMD=%TFS_EXTRACT_CMD%
SRCSRV: source files ---------------------------------------
C:\Resources\agent\_work\6\s\REDACTED\AppDomainLogger.cs*VSTFSSERVER*/REDACTED/AppDomainLogger.cs*77776*AppDomainLogger.cs
C:\Resources\agent\_work\6\s\REDACTED\CustomLogger.cs*VSTFSSERVER*/REDACTED/CustomLogger.cs*77776*CustomLogger.cs
SRCSRV: end ------------------------------------------------
Note, I have REDACTED some information, it is just pathing information I don't want to reveal, and a server name, but they are correct. If the VSTSSERVER value and source code values are correct, why isn't the source code pulled up when I try to debug. I'm not sure what those numbers are in the source code paths, and I didn't see any login credentials to log into the tfs server. However, since I'm already connected to TFS by virture of using visual studio, I thought perhaps credentials aren't needed? My build process curently does not label source .... could that be part of the problem?
I am a bit new at this (trying to use source information during debugging). Let me know if I'm missing something, and if I am, how I can remedy the situation.
I DO have the Debug -> Options -> General -> Enable Source Server Support checked (and it's two sub-checkboxes) prior to attaching visual studio to the application.
Related
I'm building a Win32 DLL project (pure C) on MSVC 14 and getting some unrelated error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(219,5): error : The source file for this compilation can be found at: "C:\Windows\TEMP\3020bf46-df05-4e6e-a019-3e0bb0f5627c.txt"
As far as I know, the stupid IDE tries to run some enforced services of MS on my code, (which I didn't ask for). I just disabled Code Analysis on project properties page, thou it had no effect.
you can either add SuppressMessageAttribute to your source code or to GlobalSuppressions.cs file, these two actions can be invoked when you right click on the specific error/warning message under the error list tab.
I've searched far and wide for a solution to this but can't find one.
I have configured TeamCity to publish packages with both the symbols and source in them to ProGet. This process works great and ProGet correctly identifies the symbols.
I have setup Visual Studio as per the instructions on ProGet's knowledge base i.e.
Adding the symbol locations in options->Debugging->Symbols
Enabled source server support options->Debugging->general
I've checked in Fiddler and the symbols are downloaded when I launch our app in debug.
Then when stepping in to one of the methods in our package it opens the wrong file. The file it opens is however named the same (we have a file called Component in each of our packages and also in local solution that pulls in the package).
If I change the name of the file and re-package and publish it to ProGet the problem goes away and I can step in to file during debugging but this seems like a hack.
Does anyone know how you can get Visual Studio to favour the file on the symbol server over any local files in the solution with the same name?
Symbol files in the project directory are always loaded, for this issue, a sample could help us understand the symbols loaded easily. If your local cache folder had the symbols file which was downloaded from the Symbol Server before, I know that it would not download it again during you debug your app. So my understanding is that since your symbol file has the same name, the VS debugging would search and load the symbol from your local project folder firstly, and then download it from the symbol server or others if your local machine has no them. That's the reason why you got this issue.
The workarounds I could think of:
(1) Load the symbols manually from Debug modules windows if you really want to use two files with the same name.
(2) Using different names would be better.
Right Click on the project containing the file you want to open and choose "Set as StartUp Project".
Now when you try to debug, it will run the correct file.
I was running a unit-test in Visual Studio today using FakeItEasy. I was offline and found the following symbol-loading to be happening and taking a long time:
My question is, where does the path Z:\Builds\work\... come from and why is Visual Studio trying to load symbols from that path. Could it be that this path corresponds to the CI that the binaries were built on? If so, is it a thing that the maintainer of the library should fix, or something that I must locally configure? I am using the FakeItEasy 1.25.2 binaries that I fetched via NuGet.
I am aware of the fact that you can disable symbol loading (e.g. see this question), but actually I want the symbols to be loaded if possible.
Yes, Z:\Builds\work\… is the path from which TeamCity builds FakeItEasy.
I'm not a big symbol user, so am not sure what you want "fixed". Why are you loading the symbols, and what behaviour would you expect in this case?
If we push the symbols to SymbolSource.org you'd still need to be online to access them, no?
Can you give an example of a NuGet package that behaves how you'd like?
How does it behave in your situation?
PDBs can be built for debug configuration and release configuration and it's typically a good idea to keep them for debugging purposes. FakeItEasy or any other DLL or EXE, contains the full path to the PDB file where it was located during compile time. If that path is part in a DLL (or EXE), Visual Studio will try to load symbols from there.
To see that information, get DebugDir and run debugdir <path to>\FakeItEasy.dll. Or, in any hex editor, search for pdb.
You'll find the full path of the PDB along with some other information. Since it wasn't you who built the DLL, the PDB is not present on your disk and you'd need to download it from a symbol server.
The Sourforge clone of DebugDir contains supports a command line parameter clean which can remove debug information. If you want to get rid of Visual Studio accessing the non-existing Z: drive, you can remove the path to the PDB file.
I using dotPeek v1.2 with VS2013 Update 3 to attempt to debug a referenced C# .dll's code. I've followed all the directions from the following tutorial: Using dotPeek as a Symbol Server (http://localhost:33417/ is set as symbol location, etc.) To be honest I've read a bunch of articles like this and this, combed through all the required settings, and really haven't seen 1 working solution of debugging a 3rd party non-framework .dll so I'm not convinced this is a fully working product from this aspect.
Regardelss, dotPeek should allow once the symbol server is started to step into and debug code from 3rd party assemblies from VSNET according to their documentation. I know which .dlls to select for dotPeek because I inspected their path from Debug -> Windows -> Modules.
I happen to have ReSharper also installed which allows me to decompile when I right click a line of code and select 'Go to Declaration'. The problem is it appears the symbol server isn't doing anything to assist in serving up the code at debug time. Rather the decompiled source provided by ReSharper seems to be what VS.NET wants to jump into. The problem is I always get the following error:
Source file:
C:\Users\username\AppData\Local\JetBrains\ReSharper\v8.2\SolutionCaches_ReSharper.Meijer.Ecommerce.Nav.WebAppServices.-382002776\Decompiler\decompiler\53\66e7ccc2\MyClass.cs
Module: C:\Projects\MyProject\bin\Debug
Process: [24808] vstest.executionengine.x86.exe
The source file is different from when the module was built. Would you
like the debugger to use it anyway?
If I say, 'yes' and step in the debugger appears to be on lines that don't exist in the file and is out of sync. This makes sense as it is showing the .cs class from the 'Source File' location but has the .dll loaded from the /bin/Debug
However, I don't understand why this is happening anyway as dotPeek should be serving up the loaded symbols from the /bin/Debug and not be trying to step into any decompiled source ReSharper had presented.
How do I configure this so VS2103 will actually debug the symbols and code served up from dotPeek?
One big gotcha is that you need to make sure you have a valid path set for the cache directory in the Tools -> Options -> Debugging -> Symbols page.
Also, on the main Debugging options page (Tools -> Options -> Debugging -> General) make sure you:
Uncheck the "Enable Just My Code" option
Uncheck the "Enable .NET Framework source stepping" option
Check the "Enable source server support" option
Uncheck the "Require source files to exactly match the original version
It's also worth checking the "Print source server diagnostic messages to the Output window" option, and checking the output window when trying to step into 3rd party code. It should hopefully point to any issues.
This is how I've got things set up, and I can debug 3rd party dlls (obviously, dotPeek needs to have the .dll loaded in the assembly explorer before you start debugging, too).
When I use Visual Studio 2010 to debug a crash dump file (native code), it attempts to load C/C++ source files from the original build folder (and it gives the message "The source file is different from when the module was built. Would you like the debugger to use it anyway?"). The message is correct; the file is not the correct version.
What I would like VS2010 to do is to check out the source file using source server. If the file does not currently exist in its original build location, VS2010 will correctly use source server and retrieve the appropriate revision of the file (from Subversion). In order to force it to check out the correct revision, I have to physically delete the file from the original build location.
As a side note, VS2005 works as desired (well ... as I desire, perhaps not as others desire). VS2005 will always check out the correct revision from source control regardless of whether a copy of the file exists in the original build folder.
I believe the question comes down to one of the following:
Is there some kind of setting available that will change VS2010's precedence for finding source files?
Alternatively, is it possible to make VS2010 offer a choice/option to check out the source file in question? (Currently the only option I see in this situation is to browse for it.)
Or is it possible to completely exclude a specific path (folder) from the search?
I have the same problem with VS2010 and made an attempt to figure it out. I monitored devenv.exe with procmon but didn't see anything out of the order with the files & registry keys it was accessing. Pretty much the same information you see in the error report when VS2010 can't find the source. My solution is to use VS2005 as it works fine. I did see some correspondence on MSDN about a similar (if not the same) bug and they claimed it would be fixed in the final release of 2012. I believe I have that final release of 2012 and it has the same problem.
Here's a maybe slightly complicated solution
1) Create a script that will download and replace the pdb file (a .bat, a python script, whatever)
2) Create a new External Tool within VS2010 (Tools -> External Tools -> Add)
3) Point the tool to your script and pass any project-specific stuff to it as arguments
4) Create a post-build or pre-build step in your project that will call your new External Tool (project properties -> Build Events -> whatever)
This is a lot of work, but at least it will fully integrate it into your building process.
Note: Sometimes I've noticed that my post-build steps won't run unless I've compiled at least on cpp file. I usually press F7 and build some source and then build fully, to make sure everything works as expected.
You can change the local source directory to a different name when you are debugging crash dump file.
Or you can change the build directory to a different path with your local directory.