I have a C# dll registered with regasm. This dll used with an older executable written in visual c++. I originally built the DLL in VS2008 on 32 bit xp. I recently moved it to Windows 8 and rebuilt it in VS2013.
I can no longer hit breakpoints in this dll. It worked just fine on the XP/2008 setup. The output directories are correct, the .pdb files are in the right locations, the setup is the same as it was before.
The only difference is that to get this to work, I had to set the target platform flag to x86 in order to get the DLL to register and instantiate correctly on the windows 8 box.
I've been banging my head all day. I've also tried to start the target.exe and use "attach process" to hit the breakpoint, but no dice. I've cleaned the .pdb files, cleaned and rebuilt, etc, to no avail.
Anyone know what I might be doing wrong?
Double-check that your symbols files are being loaded correctly during execution using the dialogue found at:
TOOLS -> options -> debugging(tab) -> Symbols
here you can specify the symbols directories in which visual studio should look for .pdb files.
I finally got it!
Debug->Attach To Process dialog.
Attach to:
Managed (v3.5, v3.0, v2.0) code, Native code. // I changed this from 'Auto'.
My target .NET framework in the DLL's project settings was 3.5. I guess the 'Auto' detect setting didn't work as I thought it would....
Related
I have a Xamarin.Forms project and referenced a dll, which I wrote. Don't know since when, but now I can't set a breakpoint in the dll or step into the dll. I'm debugging directly on an Android tablet.
First, I got the message
Your app has entered a break state, but there is no code to show because all threads were executing external code (typically system or framework code).
Then I changed the debug options and unchecked "Enable Just My Code". Now I get
No compatible code running
The selected debug engine does not support any code executing on the current thread (e.g. only native runtime code is executing).
I checked the solutions from this post, but up to now nothing of them worked:
pdb files are on the same place, where the dll is
"Enable Just My Code" was unchecked
everything in Debug mode under Build > Configuration Manager (Xamarin.Forms project as well as library)
uncheck of "Require source file exactly match with original Version" and "Step over Properties and Operators"
restart of VS
clean solutions and rebuild
clean of %USERPROFILE%\AppData\Local\Temp as described here
checked "Enable native code debugging" in the XF solution project options
restarted PC
removed app and support libraries from device
tried another device incl. emulator
It always worked like this:
checked reference to correct dll version (with rebuild)
open *.cs file from the dll project
set breakpoint or step into dll and have fun
Now it doesn't and I'm runnig out of ideas. I'm using Visual Studio 2019 (v 16.5.4). It does work with project reference, but I don't want to change the settings everytime. Or has this feature (debugging a referenced dll) been removed in VS 2019?
I ran into same error when implementning CrossMediaManager plugin, after seaching a lot, figured out that the instance should be initiated in the app constructor, i.e CrossMediaManager.Current.Init(); in the code sample below:
public App()
{
InitializeComponent();
DependencyService.Register<MockDataStore>();
CrossMediaManager.Current.Init();
MainPage = new Audio();
}
How can one debug the .NET framework source code using Visual Studio 2017?
There are some questions here on stackoverflow about this topic, but even after reading all of them, I still wasn't able to make it work.
I thought it would be useful to present an up-to-date, working solution about how to debug .NET framework source code.
I would like to solve it without using any external tools (e.g. dotPeek as source server).
First of all, I tested it using Microsoft Visual Studio Enterprise 2017, Version 15.9.7 and via .NET Framework 4.7.2. Though, I think it should work on Community edition the same way.
Steps to take:
Go to Tools / Options / Debugging / General, and perform these settings:
check Enable .NET Framework source stepping (this will automatically disable "Enable Just My Code"; if not, do it manually)
uncheck Require source files to exactly match the original version
check Enable source server support
Go to Tools / Options / Debugging / Symbols, and:
in the upper listbox check Microsoft Symbol Servers
click Empty Symbol Cache button (to make sure you will get the correct symbols)
select Load all modules, unless excluded radio button at the bottom
Download the source of the .NET framework version your project is targeting, from the https://referencesource.microsoft.com/download.html site.
Unpack the downloaded archive (zip) file to a convenient path on your PC.
Debug your application; set a breakpoint to the line of .NET code you wish to debug, and step to the desired code line with the debugger.
Note: your application may start slower since it will download PDBs from the internet.
Press Step Into (F11 by default). If your settings are correct, this will cause some delay (if your VS crashes (like mine did), Empty Symbol Cache again). Eventually it will ask for the sources of the given file, e.g. dictionary.cs.
Two things can happen here:
A) It asks for the source file (.cs) in a file dialog. Go to step 7.
B) It says whatever.cs not found, and there is a link that says "Browse and find whatever.cs...". Click that link.
Select the corresponding .cs file on your disk (you can search for the file on the OS).
Note: I had to restart VS several times until it "did not crash" while looking for sources, this is most likely a bug in VS.
If you did everything correctly, you will find yourself debugging the .NET source code.
Note: Since VS saves the path you entered for the source files, you can stop debugging or restart VS; it will work next time, too.
Besides, you do not have to manually select any more source files within the framework, because the VS will use the source folder you entered and will search in source files there.
Many people wondering why they can't step into source although they does set the checkboxes as described above. I'm, too.
Because you can extract dotnet sources to any location, Visual Studio isn't able to know about them and the reason can't be the source files itself (why Visual Studio doesn't find the files).
But some dll's are browseable, some not (through double clicking in Visual Studios stack view or context menu > goto source). This brought me to the assumption, that the .pdb itself must be the reason. If you look into a file which works (e.g. notepad), you see at beginning a list of strings with file pathes (source files). In files, which doesn't work, the files starting immediatelly with binary data.
For some reason microsoft doesn't create her .pdb's with full debug information in every build process. But why not - good question! g
In short: you have to search a dll version of your file (which you like to debug) which contains FULL DEBUG INFORMATION. This is also the reason why context menu disables "goto source".
I'm replacing this file temporary in global assembly cache for time of debug. This works for me.
Here an example of PresentationFramework.dll
- 4.0.30319.298 => pdb size: 1219 KB
- 4.0.30319.18408 => pdb size: 15.562 KB
Perhabs somebody can create a public database (wiki), which everyone can add files and versions for which full debug information are available?
(If you are like me and after following all steps you still can't step into code...your PDBs downloaded from Microsoft are wrong, try this)
Using JetBrains dotPeek as the symbol server worked for me. (4.6.2 framework) (I did everything mentioned in this thread and many more threads, and nothing worked)
https://hmemcpy.com/2014/07/how-to-debug-anything-with-visual-studio-and-jetbrains-dotpeek-v1-2/
JetBrains dotPeek decompiles your actual .NET DLLs, then hosts a symbol server that you download symbols from in Visual Studio. After a pretty slow download, then a restart of VS, I was able to breakpoint and step into the code.
You can find the path to your .NET DLLs in the "Modules" window when debugging in VS. Enter this into dotPeek. Then Host Symbol server in dotPeek. Then add http://localhost:33417 as your symbol server in VS symbol settings. then load those symbols. it takes a minute and a VS restart, but works.
I am trying to debug my DLL Class Library on Windows, but I am not able to get the debugger to stop in the source code.
Environment: Windows 10 Pro x64, Visual Studio Premium 2013 Update 5. Project is a .NET 4.5 Class Library. The executable is actually instantiated by another .exe before it calls my .dll. (I don't have source access to either of these .exes.) The .dll is in the same dir as its calling .exe, but that is not the Class Library project directory. I know my .dll code is executing, as I create new windows in my code, which are opening.
I have tried Debug->Attach to Process... in VS2013, and I connect to the calling .exe process, but the breakpoint I have set in my code never is hit, despite that code definitely being called. What am I missing here?
EDIT: This is not a duplicate of another question:
Not getting any error message
Not intermittently working
The assembly is confirmed as being loaded and executed
Your assembly might be compiled for release or compiled without any debug info. If you do things correctly, you should be able to debug by attaching to process. Another thing that can be, your code executes before you can attach to it. sometimes, especially in services, you put thread.Sleep into code, so this buys you some time to attach.
The issue turned out to be VS was not correctly figuring out what type of code to debug. In the Attach to Process window, I had to switch from Automatic to manually specify debugging Managed (v4.5, v4.0) code type in the Attach to: option, before attaching to the parent .exe process. I could then step through my source. (As it turns out, copying the .pdb file was not required - VS still uses the version of that file in the original project Debug directory.)
I am trying to debug a windows service. It's running as a console application with Topshelf. The startup project runs fine in with breakpoints and everything but none of the referenced projects in the solution seem to load their symbols. All the .pdb files are in the respective bin-folders. And a copy of all the referenced .pdb files are also in the startup projects bin-folder. Everything builds/rebuilds when i press F5.
It worked fine a few days ago and still works fine on all my colleagues PC's.
I'm sure I'm running all projects in debug mode.
I've cleaned, rebuilt and tried attaching to the process instead of just F5.
I get the same behavior in both VS2017 and VS2015.
I've deleted all the source code and redownloaded and even reinstalled all versions of VS.
None of the referenced projects show up in the Modules window. (* Actually. One of the referenced projects does show up sometimes, but I don't understand when/why. I can debug that project - when it shows up in the Modules window)
Disable the debug option Enable Just My Code (Tools -> Options)
Be advised; turning this off will slow down start up time of the debugger since loads of symbols will be loaded. It's best to debug the other assemblies in their original solution.
You can also do this, Start debugging, as soon as you've arrived at a breakpoint or used Debug > Break All. That's it
Been running into this problem lately... When debugging an app in VS.Net 2005, breakpoints are not connected. Error indicates that the compiled code is not the same as the running version and therefore there's a mismatch that causes the breakpoint to be disconnected.
Cleaned solution of all bin file and re-compile doesn't help. Not just happening on a single box or person either.
Added Note:
This solution is in TFS for Source Control. If I delete my local TFS repository and get it from source control from scratch, SOMETIMES the problem goes away. I've also tried un-installing and re-installed Visual Studio. That also SOMETIMES helps. That fact that both of those work some of the time indicates that the problem isn't caused by either directly.
Maybe this suggestion might help:
While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
Look for your project's DLL, and check the Symbol Status for it.
If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
I've found that it's sometimes necessary to:
stop the debugger
close the IDE
close the hosting application
nuke the obj and bin folders
restart the IDE
rebuild the project
go through the Modules window again
Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.
Source: The breakpoint will not currently be hit. No symbols have been loaded for this document.
http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/
In Options -> Debugging you can uncheck "require source files to exactly match the original version", which may help.
Is the build configuration set to Release?
Do you have a reference to an external DLL where the breakpoint is set?
Are you creating a DLL project that is consumed by an external executable? Are you using .NET or COM?
If you are using the COM Interop with .NET, the DLL versions can sometimes be a problem when the executable loads the DLL. For instance, if your daily build cranks out an incrementing build number but your debug DLL has a smaller build number, the executable won't load the debug DLL. To fix this, you will need to scan the HKEY_CLASSES_ROOT\CLSID directory in your registry for the GUID/CLSID of your .NET/COM component. Under InProc32, delete entries with a higher version number than your debug DLL.
Again, the above only applies to .NET + COM Interop DLLs.
I've had a similar problem in the past.
It was solved by closing Visual Studio and deleting the temporary ASP.NET generated assembly files for the project under "C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files", re-opening the project.
Read the post here and the comments to resolve it.
AviewAnew - had already done that at the request of the MS tech person. It didn't help to uncheck require source file to match version.
Mike L - configuration is set to DEBUG and there are now external DLL. Using all local projects except framework references.
Are you sure the .pdb files are in the same folder as the executable you are running? Make sure the last modified date of both files match, and that VS is attached to that exe (and no other).
Do you have a post build step that touches your binaries in any way? If so, this can confuse the debugger and make it look like your symbols don't match your exe/dll because of the incorrect size/timestamp.
In the past I have sometimes found that switching off compiler optimisations can solve 'missing' breakpoints, as the optimiser had determined (correctly) that the code was not being called, and removed them from the compiled versions.
This does sound like a different issue, but it might be worth making sure that optimisation is switched off in Debug mode. [Project / Properties, Build settings tab]
Sure there are no Debug attributes on the code that prevent code from being debugged, such as DebuggerHidden or DebuggerStepThrough, at any point of the application?
Can you step through your code up to the line of the breakpoint instead of running and waiting for it to hit? Can you step through code at all?