I have a C# application that can be launched from the windows explorer context menu when certain file types are selected:
I need to be able debug the application from the first line of code (ie I don't have time to launch it and attach to process) Is it possible to debug my application in visual studio when I launch it from the context menu?
If the application is already running, just select Debug -> Attach to Process and then pick the process from the list.
If you are trying to debug the startup code of your application, you will need to try another approach because the code will be done executing by the time you are able to attach to the process. In this case, if you are able to modify the code (and it sounds like you are), I would recommend adding this code somewhere in your application startup:
Debugger.Break();
When the process hits this line, it will pop up the dialog which says "would you like to debug?" and you can say yes and it will attach the Visual Studio debugger, with execution paused at that line.
Here is the docs for the Break() method:
http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.break(v=vs.110).aspx
From the Microsoft documentation for Debugger.Break() method:
Warning
Starting with .NET Framework 4, the runtime no longer exercises tight control of launching the debugger for the Break method, but instead reports an error to the Windows Error Reporting (WER) subsystem. WER provides many settings to customize the problem reporting experience, so a lot of factors will influence the way WER responds to an error such as operating system version, process, session, user, machine and domain. If you're having unexpected results when calling the Break method, check the WER settings on your machine. For more information on how to customize WER, see WER Settings. If you want to ensure the debugger is launched regardless of the WER settings, be sure to call the Launch method instead.
Related
I realize this sort of question has been asked before, but I have a very specific (and a rather complicated) case that is subtly different, so the usual solutions either do not work or do not apply.
Basically, I have a console app which is launched by a VSIX debugger launcher. The purpose of this app is to load a hosted DLL, establish the appropriate environment, and allow debugging of the DLL's source code from Visual Studio the same way a normal C# project would be debugged. The difference is that this project is not an executable, but a library, and so it needs a host (i.e. the console app in question). It's all very similar to how ASP.NET projects work with IIS/IIS Express - it's just that I wrote a custom host and I manage its launching from my custom VSIX.
The custom host app is a .NET Core Console app and the debugger launches it without any windows. This is deliberate, since it needs no interactive input and all output is redirected to the Visual Studio's debugger session (i.e. the Events tab).
The app is also generic, so it can't know the name of the debugged project until it's actually started. On top of that, I can have multiple instances of Visual Studio debugging multiple different projects at the same time!
I would really like to ease differentiation of these processes in Task Manager, so that they each showed as the name of the specific DLL project that is being hosted in each respective instance. My attempts so far have been:
// 1. This crashes with InvalidOperationException because there is no window.
Console.Title = loadedDllProjectName;
// 2. This doesn't crash, but has no effect, either.
[DllImport("user32.dll")]
static extern int SetWindowText(IntPtr hWnd, string text);
...
SetWindowText(Process.GetCurrentProcess().MainWindowHandle, loadedDllProjectName);
FWIW, the Task Manager shows the process under its default image name and lists it among background processes. The latter is fine and expected. But I would like to change the former. How?
UPDATE
According to this, my pursuit might sadly be hollow. Still hoping for an encouraging hint, though!
So I am trying to debug a process in MVC4. I send the POST request, watch it manipulate the database, etc etc. However, after I have seen the information I want to see, I click "Stop Debugging". In any typical GUI .NET application, I would think that the process would terminate, but it instead continues to execute. If I make any changes in the file and try to debug again, the breakpoints will not be hit because the files are not out of date from the previously ran process which is still running. I have 2 choices at this point - let it run or kill the w3wp.exe task with the Task Manager in order to continue debugging.
I have tried to click Debug -> Terminate All, but the process still continues to execute. I know this because I attach to the process (Debug -> Attach to Process) and it pauses at one of my many breakpoints throughout its execution.
Let it be mentioned that I am using Google Chrome to send the POST requests to the Controller, so it may not be terminating because I am not using IE - however, I do think that there is a better solution then using the IE browser.
In order to work around this, I have to go into the Windows Task Manager and kill the IIS process (w3wp.exe), which seems downright messy. Any ideas?
If I make any changes in the file and try to debug again, the breakpoints will not be hit because the files are not out of date from the previously ran process which is still running.
Once you modify any code file you require to re build the solution and then again Debug -> Attach to Process.
Please also note that Stop Debugging does not mean that it will kill process always. It will kill only Visual Studio Web Development Server or sometime IIS Express process with Visual Studio. Here you mentioned w3wp.exe. While this process is managed by IIS.
Couple more graceful ways to restart your w3wp worker process:
in command line, run "iisreset"
in IIS Manager console, select the corresponding application pool and click "recycle"
For a graceful shutdown of a long-running business logic, try Application_Shutdown event in global.asax.
For not-so-graceful approach, ThreadPool may help you - threads on it are marked as Background and thus Windows won't wait for them to complete when main thread of w3wp exits. However this approach doesn't always work, because 3-rd party libraries (especially networking) may create non-background threads that, again, will delay shutdown.
For even faster and dirtiest, use Environment.Exit, triggered by some debugging-only event. http://msdn.microsoft.com/en-us/library/system.environment.exit(v=vs.110).aspx
My program uses MSSQL database and has been working fine. However, after making some changes including converting from VS2008 to VS2010, generating 32bit application. It starts having the following strange problem:
When I try to shutdown the console by clicking the system menu(X button), it does not shutdown, you can move the console around, you can also click on the left hand system menu such as properties, etc, but the program does not show up on the taskmanger's processes tab, therefore, there is no way to shut it down, but to restart box.
Also, while the program is in this ghost mode, I can actually start another instance. That means the ghost application already release most of the resources such as file handle, db etc.
The problem seems to occur after we have some issues with ms-sql server, such as time out exception. I simulate the situation by throwing an exception in the same db function call, but that does create the ghost situation. box is Windows Server Standard without Hyper-V, SP2, 32bit.
Can you reboot your computer after 'ghost application' appears?
If not, check this http://support.microsoft.com/kb/982551/en-us
I have a .NET application deployed across 28,000 workstations currently. On all of them, that process is launched at user login from the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run registry key. On most of those workstations, it works fine, but on a few, it crashes when running in this way. Annoyingly, launching it manually after login works fine, and no crash happens.
So I'm trying to work out how to get WinDbg up and running and attached to this process in time for me to try to get a memory dump and at least some idea of what's going on.
How can I do that? As far as I'm aware, the order of automatic start-up of applications is not guaranteed on Windows (It's WindowsXP SP3, in case that matters), and so this isn't going to be super easy.
One of the ways to do it is GFlags. Gflags can be instructed to attach to the debugger when the process launches.
And debugger script can be passed in the command line to get a memory dump when the process terminates or throws an exception.
One way to achieve this would be to deploy a custom build of your application on the workstation that exhibits the problem. That build should call Debugger.Break() as soon as possible in order to trigger the default JIT debugger.
If you set the necessary registry keys so that WinDbg is registered as the default JIT debugger, it should attach to your application when it starts, allowing you to get a memory dump.
I would like to know if there is a programmatic way of determining at run-time if the application was launched via the debugger or by launching an installed version of the application. My app is currently being deployed via ClickOnce.
There are certain settings I would like to alter when the app is run in debug mode vs production mode.
I am aware of the build configurations solution -- I am curious if there is a programmatic way to determine this information
Thanks
Use Debugger.IsAttached.
It is a static method within the System.Diagnostics namespace, as you can deduce from the name, it will return true if the debugger is attached (whether it was attached after launch or not).
You can put this in the application entry point (main) in order to find out if the application was lauched with a debugger attached, but keep in mind that it can be attached at a later time.
As mentioned, you can use Debugger.IsAttached. However, be aware that this doesn't necessarily mean that the application was launched by the debugger, it may have been launched normally and then a debugger was attached to the process (I don't know if the difference is relevant for you).
To tell if it has been launched in the VS Debugger:
if(System.AppDomain.CurrentDomain.DomainManager.ToString().ToLower().Contains("vshost") == true)
You can use: Debugger.IsAttached
The Debugger class is a class worth looking at. It contains some nice goodies.