I am developing an application using Visual Studio, and when I install it (via Setup Project, .msi file) in a client machine and run it, I get some "Heisenbug" exception.
I am almost sure the error comes from earlier in the codepath, so I would like to debug it.
Fact is: when the application crashes, the following dialog is displayed (referring to my application instead of Windows Explorer, of course):
and if I choose "Debug the program", the Visual Studio Debugger (which is somehow available in the deployed machine) starts and shows details from the exception.
What I would like to do is to start the debugging session from the very start, so I can go on hitting F10 and F11 and check some intermediate values.
Anyone know how can I start the Visual Studio debugging session at any time while the application is running? Not that I am running the deployed application, not starting it from Visual Studio.
Since you have Visual Studio up and running on the machine running the deployed application, it should be straightforward:
Run the application
Load the project in Visual Studio
Go to DEBUG -> Attach to process...
A list will pop up with all the running processes
From the list, pick the process corresponding to the application, it should be named after your exe (if you sort by the numeric IDs, it's very likely it will be near the highest end)
Click "Attach", Visual Studio will should start debugging similarly as when you normally start with F5.
I also have another suggestion: implement heavy logging until you have everything figured out. Write down everything you have doubts about for further analysis in case something goes wrong: values, queries, etc.
You can start the application directly under the Visual Studio Debugger using the debugexe parameter:
devenv /debugexe “C:\MyApplication\Debug\MyApplication.exe”
This will launch the application with the debugger immediately attached. Otherwise it's very hard to debug issues that happen at the time the application is starting. You won't be able to manually attach in time to catch any events that happen during this time.
You can also place the following piece of code at the first line of you application (usually the Main(string[] args)) to force a debugger to attach and cause the application to break immediately:
System.Diagnostics.Debugger.Break();
If your application starts and runs fine for some time, you can use the "Attach to Program" feature as described by #Alex.
If you don't have the sources available on the target machine, you can either copy them over, or if you're using Source and Symbol Indexing features of TFS Team Build, you can tell the debugger where to look for your Debug Symbols (which will then resolve to TFS source control automatically).
Related
So I'm now using Visual Studio 2019 in C# .Net Framework.
I have been programming in Visual Basic 6.0, and when I pressed F5 the IDE run and if there were errors while debugging if I pressed the X to close the Vb6.0 IDE. a message box prompted saying if I wanted to save the changes since there were errors while debugging I pressed no.
Now in Visual Studio 2019 using C#, that doesn't happen. If I press F5 and an error occurs while debugging, it autosaves the solution with its error. How can I stop it from saving with the error in it?
No, you can't debug code that hasn't been saved with Visual Studio. If you want to see the process it goes through, do this:
Open Tools -> Options
Click "Projects and Solutions", then click "Build and Run"
Change "MSBuild project build output verbosity" to "Normal" (or, if you want to see a lot of stuff, "Detailed" or "Diagnostic"
Rebuild your project
You'll see VS invoking the compiler and passing the paths to each of your file (and to all of your references) to the compiler. It needs to save and to compile and then execute your code.
The VS debugger is a full Windows debugger. Open Windows Explorer, double-click your EXE. Now open VS, in the Debug menu, choose "Attach to process" and choose your running EXE. You are debugging it (you can attach to any process you have rights to, but attaching to a debug build where symbols are handy give you the best experience).
BASIC and pre-.NET VB started their lives as interpreted languages. A pre-processor would take your source and convert it to tokens. Then an interpreter would interpret those tokens as it ran your programs. Though the last few versions of traditional VB could compile your code to an EXE, that interpreter was still there.
In particular, the debugger used it. When you ran the VB6 (and earlier) debugger, the debugger didn't debug your program, it debugged your source - injecting itself into the interpreter, not attaching itself to the EXE. That's why the behavior you are asking about worked.
As I mentioned, getting a Source Code Control system set up (which is always a good idea) will help you get close to what you want. Git's probably the easiest to set up. Visual Studio Team Foundation Services (or whatever it is called this month) is also a possibility.
I've written a basic program using Xamarin.Forms. I can run the UWP version of the program completely fine in both debug and release mode from Visual Studio 2017 with no crashes. However, if I try to run either the release or debug .exe directly from the file explorer, the program loads, but crashes almost immediately afterwards. There's no window that pops up for a split second; the program crashes without a trace. The same situation occurs on different computers. What's strange is that I could run either .exe directly about a week ago, and that everything stopped working only recently.
If I check the event viewer, I get a .NET Runtime error that states this:
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
I'm assuming this has to do with a blocked DLL or something auto injected by Visual Studio that isn't included in the build directories. However, I am unsure where I'm supposed to go from here and I've pretty much hit a brick wall in terms of research. How can I get the .EXE's running from the file explorer again?
Currently I am developing a global exception handling in a .NET C# application. I get some strange behavior:
If I debug the application from Visual Studio (F5), an unhandled exception causes the main thread to be terminated.
If I start the application without Visual Studio (click on the .EXE) with the exact same compile output (DEBUG-Build), the App doesnt crash after an unhandled exception occured.
This is kind of weird behavior...Does anyone know what's going on here?
EDIT:
It seems as if something changes within the running code as soon as a debugger attaches to the process... If I start the App without Debugging from within VS, the App doesnt crash.
I’ve been doing some work with ASP.NET MVC but was having periodic issues with Visual Studio 2008 hanging (freezing / becoming unresponsive) when I tried to run my web application with debugging. The problem only occurred with a specific web project.
I tried deleting the Temporary ASP.NET Files (%userprofile%\AppData\Local\Temp\Temporary ASP.NET Files) but that did not solve the problem.
I tried deleting the obj folder. No luck.
I tried waiting it out one evening. I eventually feel asleep and when I awoke sometime in the middle of the night, my web app was happily waiting for input and Visual Studio debugging was completely responsive. That proved to be a temporary salve.
showallfiles The problem resurfaced again a few days later and I finally figured out the problem with my uncooperative debugger. I have a folder containing approximately 20,000 images that are not included in the Visual Studio web project but are sitting in a directory in the web site. I had turned on "Show All Files" in Solution Explorer to add some script files into the project. When "Show All Files" is off, F5 (Start Debugging) works like champ. When "Show All Files" is on, Visual Studio becomes unresponsive. In reality it is not "frozen" but simply taking a very long time to process those 20,000 image files.
Mystery solved.
I have updated Visual Studio 2015 to the first update. Since then I cannot debug my code twice in a row. It goes like this:
I start VS and try to debug. So far OK
Change code, build and debug.
Try to reach a web but it never loads.
If I close the VS and load the solution again it works or If I do not change code in step 2.
Other thing I noticed is the IIS Express Worker process is consuming most of CPU time.
And apparently the symbols are not loaded (I do not see the messages of DLL loading in the status bar).
This is making my development process very slow and tedious.
The solution is a MVC project under 4.6.1 framework.
Any ideas? Thank you very much!!
You should boot Visual Studio into Safe Mode. To enter safe mode do the following:
Open Command Prompt, as Administrator.
Enter: cd C:\Program Files (x86)\Microsoft Visual Studio 14.0
Enter devenv.exe /safemode
If Visual Studio does load and debug, then more than likely an extension or an update is the culprit. This will allow you to also see which updates may have occurred. The other potential issue would be if your Internet Information System had an issue.
Otherwise if your Internet Information System is stuck 'on'.
CTRL + ALT + DELETE
Go to processes, end W3P process.
Try to launch and debug inside Visual Studio.
Otherwise, simply try restarting your computer. We would need more information, as this can occur for an assortment of reasons.
#Julen - I have the same issue as you and I have found a work-around.
Add the "Terminate all" button to your toolbar and use it instead of just stopping the debugging. This command kills the IIS Express process.
See how to add it here:
Automatically Kill IIS Express Process After Debugging (VS Express 2013 Web)
If your IIS doesn't shut down after stopping the debugger, you could do one of the tricks written in this blog post - but the opposite way because the article focuses on keeping the debugger on.
Here is the proposed solution 2 - to check "Enable Edit and Continue":
Similar to VS 2013, if you disable Edit and Continue IIS Express will continue to run when you stop your debug sessions.
Open the menu item Tools/Options, look for the Debugging/General option. Scroll down and uncheck “Enable Edit and Continue”
It might be hanging when trying to load external symbols. I had a problem with that before.
To test this theory:
Open the Tools menu.
Click 'Options'.
Find and expand 'Debugging' on the left.
In the 'Symbol file (.pdb) locations' list, uncheck everything.
Click OK and see if the problem reappears.
I just migrated to Windows Ultimate 64 SP1, because my system's hard drive crashed. I installed Visual Studio 2005 SP1 and all the patches that Microsoft has recommended. I finally got my source code from my SCM, but now debugging does not stop on any of my breakpoints I have set. This is just a plain Winforms app, nothing fancy.
The first thing I did was to change the build target to x86. No dice. Then I went and downloaded Debugging Tools for x64, still no dice. I set the debugger to break on all exceptions both handled and unhandled. No dice either.
I've been looking at Google search results, but no luck there either. I've been at this for 3 days now with no luck. Has anybody dealt with this issue before?
Update:
The projects are all set to Debug (x86).
Breakpoints stay normal when the debugging session starts.
I already did a re-install, and that didn't work either.
I am running as Administrator and turned off UAC.
I attached to the project using "Attach to Process", and I was able to step into the code that way. I'm hoping to find out why it is not auto attaching, in order to avoid having to do this manually every time.
This is listed as a known issue for VS2005 on Vista (Via MSDN):
Title: Just-In-Time (JIT) Debugging of
an elevated process will fail
Description: Elevated processes cannot
be JIT Debugged by VS 2005. This
includes system processes, such as
IIS, and applications started by
selecting ‘Run as administrator’.
Workaround: The debugger must be
attached manually before the debugger
will catch unhandled exceptions or
user break points
(System.Diagnostics.Debugger.Break,
__debugbreak, etc).
Couple of questions.
When your code fires up, does the breakpoint become an empty circle with a tooltip that indicates that the breakpoint won't be hit? Or does it become a full circle with a tooltip that indicates the process it's attached to?
You can try manually attaching the debugger to see if you get any traction that way. Just fire up the app and once it's running, go to the debug menu and choose "Attach to Process" - select the process that your app is running in and click "Attach".
I run Vista64 w/o issues - VS2008, though.
I am using Visual Studio 2005 with the same patch level on both Windows Server 2008 x64 and Vista x64 SP1 without any issues.
Are you running it as admin? When all else fails, try uninstalling and reinstalling.
Insure that the project is set for a debug compile and not a release compile, as the release compile doesn't contain your debug information.