Is it possible to attach the Visual Studio to a process right at the moment when that process starts? Ideally I would like for VS to listen to processes starting until one meets a certain condition, at which point it would immediately attach itself to that process.
In other stack overflow questions I've seen the suggestion to start the process from my own visual studio instance, but in my situation this is not possible. I need to attach VS to a debugger thread in another VS instance with an SSIS project. The debugger thread must be started by that VS instance. I can not attach my VS instance to the process quickly enough by hand to debug certain processes that happen immediately at the start of the thread.
System.Diagnostics.Debugger.Break()
It's not solution for all cases but simple way is to add this code at begining.
I didnt have VS on remote station but I was able to attach remotely and bellow lines saved my day
For Windows application
Windows.Forms.MessageBox.Show("wait attach process and click ok");
For ConsoleApp
Console.WriteLine("wait attach to process and press any key");
Console.Readkey();
Related
Visual Studio 2010
To stop the debugger where it currently is, I normally use Break All from Debug menu.
However, now I'm multithreading, and this does show me a place in code, and it says this is where thread A is going to execute when task is back to it.
However, right now another thread is frozen somewhere, and I'd like to access the one which is currently running. How can I do that? To know the active thread and the last line of my code it did?
Have you tried DEBUG > WINDOW > THREAD ?
It will show you your currently executed thread (where your task is actually waiting) as well as other worker threads running. You can double-click on the thread you want to access its callstack and then see why it is blocked.
You just use the Threads window. Debug > Windows > Threads. Then you just click on the thread your interested in.
I use a Visual Studio plugin to freeze all other threads so when I step through the code it doesn't jump between the threads.
Debug Single Thread
Ctrl+S, D opens the Parallel Stacks window in VS 2010
Other Versions have similar functionality: See MSDN
Further reading: Walkthrough: Debugging a Parallel Application
Situation:
I'm currently debugging an application which has many threads. I put a debugger points in my code, and at this points I know I have 10 threads and everything is fine. However on the 5 fifth step, my application crashes.
Problem:
I'd like to know if that is possible when my code is stop, to monitors every thread which make a step? So I can find which one cause the crash.
In VS 2013 go to Debug > Windows > Threads (Ctrl + Alt + H) menu. This will open a window where you can see all threads. You can pause threads you want and execute what ever you want. hope this helps
I need to create running windows process (the one seen on task manager) when a Windows form loads because I need this application to be monitored by nagios (http://www.nagios.org/).
So when the form loads, an exe will run in the background process, and when form closes, the process will have to stop too.
Update
So when the form loads, the current ApplicationName.exe will display in the Task Manager Processes Tab, and when form closes, the ApplicationName.exe will have to stop too.
I also found out that when you Start Without Debugging, the ApplicationName.exe will display in the Processes Tab of the Task Manager but if you Start Debugging (F5), you wont see the ApplicationName.exe in the Processess Tab. Now i want to make sure that even if I will Start Debugging it, I can still see the ApplicationName.exe in the Processes Tab. How do i do that?
Clarification needed: is the additional process that is running the Nagios monitor, or something else you create?
Either way, you can use Process.Start() to kick off a separate application from within your own:
//event handler for the form's Load event
public void MyWindow_FormLoad(object sender, EventArgs e)
{
//kick off the process you want
Process.Start(#"C:\Program Files\MyOtherApp\MyOtherApp.exe");
}
There are overloads allowing you to specify arguments, or customize the startup behavior of the process. But this is the basic call and (given a real program location) should kick off the separate EXE as a new process with default startup behavior (as if you'd double-clicked it in Windows Explorer).
Now, if you need more, like a way to have the two programs talk to each other, then you'll need to expand your question with the appropriate details.
EDIT FROM COMMENT: Ah. OK, that's slightly different.
Normally, any EXE that is running at any given time will appear in the Task Manager's processes list by default, with no special coding necessary. It's in fact very hard to get a proces to NOT show up in that list, because a process that doesn't want to be seen is one of the hallmarks of a virus.
However, when you run an app in Debug mode from Visual Studio, the code is compiled and run from within VS's process boundaries, and doesn't show as its own process. To get it to show up as its own process in Task Manager, the compiled application must be run from outside VS. You can still debug it, by "attaching" VS's debugger to the running process after you have started it. But, this means that the app must be stable and long-running enough for you to manually attach to it. A program that has finished most or all of its execution by the time it reaches a "resting" state will need some modification in order to wait for you to attach to it before doing whatever it was you wanted to debug.
I have Test.exe ,a sample winform app. and used it as Process
public Process process = new Process();
protected override void OnLoad(EventArgs e)
{
process.StartInfo.Verb = "open";
process.StartInfo.FileName = "Test.exe"; //Give your App or Process Name
process.StartInfo.WorkingDirectory = #"C:\Users\sali\Documents\Visual Studio2010\Projects\Test\Test\bin\Debug"; //Give your App or Process path
process.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
process.Start();
}
I hope it helps
Or if you require something different, feel free to ask
If you just want a Windows form application you have written to show up in the list of processes when it runs then you will find it does anyway. You do not need to do anything special for it to run in its own process. For example I made a simple out-of-the-box Windows form application in VS2010
And then ran it (without debugging) and here it is in the process list of Task Manager.
(N.B. I'm running Win8, so your Task Manager may look a little different.)
If however you need to know when a Windows form application not written by you is started and stopped by the user you'll need to look at Windows hooks as mentioned in the answers to this question or at the process creation/modify/shutdown events in the Windows Management Instrumentation(WMI) API.
I have a C# application which makes use of the Microsoft Windows API Code Pack - in particular the Shell Extensions, which I use to monitor storage devices and media insertion and removal.
However when I attempt to close the app in Visual C# 2010 (Express) I then have to manually stop the debugger. It appears that there is a background loop in the Win API Code Pack that is still running, even when I manually dispose of the ShellObjectWatcher. The only way I can kill it is to manually stop the debugger.
The app is built in WPF.
Eventually, VisC#2010 gives up on trying to run the app under the debugger. You tell it to start debugging and it just doesn't. Only way to get it going again is to kill the app using Task Manager and then shutdown VC#2010 - go have a coffee - then start it up again. Odd. I suspect there is a hidden process or window hanging around which isn't being shut down when I try and clean up the app.
Any idea how I can clean up this ShellObjectWatcher a little more effectively?
To fix the bug in the Code Pack Shell project, add one line in MessageListener.WndProc():
case (uint)WindowMessage.Destroy:
**_running = false;**
break;
Now ThreadMethod() will exit the message loop.
OK using System.Environment.Exit(0); fixes this issue. App shuts down and the debugger releases control. Brute force works in this case.
I bumped into the same issue, but solved it by setting the thread as a background thread (meaning, it is killed when the application stops):
in MessageListener.cs, in the constructor, at line 40, I have:
_windowThread = new Thread(ThreadMethod);
// The line below will force the thread to terminate when the app exits.
_windowThread.IsBackground = true;
_windowThread.SetApartmentState(ApartmentState.STA);
I am trying to attach to a windows service using Visual Studio 2010 → Debug → Attach to process command. When I scroll through the list of processes my Windows service is greyed out and the attach button is also greyed out.
I have tried changing the service account to local service, my account, etc., but it remains greyed out. Is there a way to troubleshoot this?
I usually have the same issue and I take care of it by adding a boolean to my configuration that triggers a debug launch. You can launch a Visual Studio debugger instance that attaches to your Windows service process by calling this:
System.Diagnostics.Debugger.Launch();
What's nice is that you can call it wherever you wish in your code.
In Visual Studio 2010, on the 'Attach to Process' dialog, check the two check boxes at the bottom that say 'Show processes from all users' and 'Show processes in all sessions'.
On doing that I found that I had my process show up twice, one running as System and one running under my local Windows login. I am not sure why (any input on this would be great!), but I was able to attach to the not-grayed-out one that showed up and was also able to step through my code this way.
The second one was the servicename.vshost.exe process as Ozz pointed out in the comments.
If you still do not see it, make sure your service is still running. Sometimes you might have a failing service that started and automatically stopped and therefore doesn't show up in the attach to options.
Not only did I have to select show processes from all users and the show processes in all sessions check boxes; I also had to click the Select button and then choose the Managed code.
Make sure you run Visual Studio as an administrator. It will require administrator rights to attach to a running service.
After installing the Windows service, start it. Then in Visual Studio open the Attach to process window (Alt + Ctrl + P), find your process and select it and click Attach Button in the bottom of the window.
You may not have permissions to attach to the service. Do you have admin privileges on the desktop? Many corporations do not allow this by default, supposedly to assist in securing their environment.
I solved my problem by changing the way the setup was generated, from RELEASE to DEBUG. And then, I installed the service and attached as usual.
I ran into the same issue today with none of the previous solutions working. As it turns out, it is not possible to attach to a process if you have a ProcDump session monitoring that process.
Use menu Tools → Attach to Process. Simply check Show Processes from all users at the bottom left. Sort by Process and try looking for your Windows service.