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
Related
I have a console job for generting pdfs(to generate 10000 pdfs)
When executing through task scheduler I am facing error "window handle exception" after generating 1100 pdfs
When executing manually or from command prompt, job running successfully and generating 10000 pdfs.
Can any one suggest what may be the issue while running through task scheduler.
Suggest me any software to find any memory leaks, GC Collect, Windows Handles utilized.
What about attaching to the actual process when the task scheduler launches the app? In Visual Studio, Debug > Attach to Process. If the exception is happening right away, you can add a delay to your program so you have time to attach.
System.Threading.Thread.Sleep(120000); //Sleep for two minutes
That way when the exception is hit, your IDE will break on the line and might give you more detail in the inner exception.
If you app runs on a remote server you can install the remote debugging tools and still attach to the process.
I am developing a windows form in c#. It is working fine but when I am running it in debug mode, I can see that visual studio is not stopping even after closing the form.
Below are some screenshots-
and
Probably my app is not releasing any resource. How can I deal with this problem? How to know which resource is still in use?
This can happen if you are using ApplicationContext instead of a form as the default message queue. If so, consider handling the form closing event of your form.
When I have seen this issue in the past it was because my application hasn't actually exited. This would most likely be because you or a dependency still has a thread running that hasn't stopped. You can tell if this is the case by looking at the task manager and checking for yourapplication.exe or yourapplication.vshost.exe. If either of these is open in the task manager you can kill it.
To fix this issue, make sure you call Abort() on all threads!
You might want to try looking at the Processes from Start Task Manager. That could give you some information if a third party process initiated by the application is still running.
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.
I've worked on quite a few WPF solutions, and this is the first time i am seeing this problem.
Today it started happening intermittently. where after closing my WPF window, the .exe is still running under visual studio.
so i have to kill my program.exe manually in order to compile again.
Initially i thought because i overrode application start/exit/exception .. but i commented all that out, and it is still happening.
In fact, i see multiple instances of my program.exe in process explorer!
Can't figure out what is causing my exe not to exit. Is there any explicit dipose logic i can add in applicaton exit event to ensure it really exits?
My application consists of single window, and multiple user controls as views.
update
if i open in debug mode. and close the main WPF window, my visual studio does not stop debugging. however call stack window is empty.
You can use the Application.Exit event to log when your application shuts down.
Alternatively, you can attach the debugger to your running instance (even if it wasn't started in the debugger) then pause it to see where it's at. Make sure to look at the Threads tool window, as you may pause outside the UI thread.
This should take care of it, though its probably better to try to figure out the underlying issue.
System.Diagnostics.Process.GetCurrentProcess().Kill();
What might cause an executing process from windows service to run slower than running from command line?
When I execute a process(another exe) from teh command line with admin rights, it is four times faster than when a windows service executes the same process. What could be causing this.
Permissions on directories and files are okay for the account. It runs successfully, just 4x slower. Need ideas on what to investigate to figure out the problem.
We have been using sysinternals processexplorer and not seeing anything.
Where is the advances tab with the ability to modify the "priority" to see if that is causing the problem?
In Windows background services may be given less priority, and that is configurable in the advanced tab of computer properties.
Assuming the priority of both applications is the same, you need to profile the app and see which calls are taking the most time. That should at least give you enough detailed information to come back and ask "why is this specific call running slowly" instead of "why is my app running slowly".
Download the sysinternals process monitor tool from www.sysinternals.com and then start tracing the application, that will show you what the process is doing in terms of registry / file access and will potentially show up what to look at when the delays are occuring.
If you have the debug symbols it can also give you the function call name in the dll / app that is being called, but even knowing what is occuring when a delay occurs and what dlls are in use, user mode or kernal gives you a good indication where to start.