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.
Related
For two weeks, each day since I installed Windows 7, I have been struggling to get something to work. Something which worked perfectly ok in XP. It's driving me mad, poisoning my life, ruining my days. Why such a simple task works SO CHAOTICALLY!?
I think I discovered a bug in Windows 7, specifically in the way the ShowWindow function works in the standard theme (Aero).
To demonstrate this, I uploaded 2 C# WinForms applications and their source code.
http://www.axonnsd.org/W/P007/BugsDemo.rar
HideableApplication represents an application which you can hide in the SysTray when you close it. Double clicking the SysTray icon reveals it and right clicking will reveal the "Exit" option.
HideableApplicationRevealer attempts to show HideableApplication's window.
The reason I need to accomplish this task is because I minimize my Total Commander and FireFox to the Tray and I want to bring them back via a HotKey. Total Commander offers such a functionality but it is broken.
On Windows XP I managed to accomplish both these tasks without any problems, using the code I attached.
On Windows 7, the behavior is erratic at best, and non-functional at worst.
When HideableApplication runs inside Visual Studio everything works:
Trying to reveal it via HideableApplicationRevealer from Visual Studio => SUCCESS
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => SUCCESS
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => SUCCESS.
When HideableApplication was executed manually (via .exe from Debug folder) AND Visual Studio IS STARTED, it works if I use admin rights or run it manually:
Trying to reveal it via HideableApplicationRevealer from Visual Studio => FAIL
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => FAIL
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => SUCCESS.
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut (start menu) which has been given ADMIN RIGHTS => SUCCESS.
When HideableApplication was executed manually (via .exe from Debug folder) AND Visual Studio HAS BEEN SHUT DOWN: it only works if I run it manually (double click exe):
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => FAIL
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => PROBLEMS: Window blinks on the TaskBar instead of being shown!
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut (start menu) which has been given ADMIN RIGHTS => SUCCESS.
If it matters, I reproduced this behavior both with the Taskbar in its standard position AND also with it set to AutoHide, in the left of the screen.
Apparently, I need admin rights to show a window, but even like this, it doesn't work right when I use the Scheduled Task workaround (create Scheduled Task with admin rights and invoke the Scheduled Task via system32/schtasks.exe /run /tn "task name"). What happens is that AFTER VISUAL STUDIO IS SHUT DOWN, the window blinks on the TaskBar instead of being shown (and has no focus). It does appear, but it has no keyboard focus, which should NOT happen because I also used the SetForegroundWindow API.
This is exactly what happens when I try to run reveal Total Commander as well: read below, same behavior: blinks on taskbar instead of being shown.
And don't even get me started on the difference in behaviors between when running it from Visual Studio and when running it from its usual C:\MyProjects folder.
My TotalCommanderRevealer and FireFoxRevealer exhibit even stranger behaviors: when starting Visual Studio, the Total Commander app stops working properly. Even if I load NO PROJECT, instead of showing TC to me, it just blinks it on the TaskBar. However if I open the TCRevealer project, it starts working again! If I shut down Visual Studio, it STOPS working UNTIL I RESTART WINDOWS.
The FireFoxRevealer instead of revealing FireFox, does something very strange: it shows a small label in the top-left corner of the screen, usually with something related to the opened tab. I suspect this has to do with the Window Style and the way the ShowWindow function works in Windows 7. However, sometimes it works, showing the actual window. But most of the time it doesn't. And when it stops working, I never get it to work again until certain unknown circumstances occur and it works again. Regardless, this worked pefectly under Windows XP and does not work at all now.
If you wish to reproduce the FireFox issue, use the code I attached: instead of searching for "Hideable Application" text in FindWindow API, search for "MozillaWindowClass", install FireFox 7 or 8 and install the FireFox "Minimize To Tray Revived" addon.
I should also mention that I'm aware of the "ForegroundLockTimeout" registry setting and I have set it to 0 everywhere it appears in the Registry. On Windows XP it is set by default to 0 but in Windows 7 the default value was 200000, which I have changed. Maybe somehow it lingers somewhere??? And Visual Studio, while running, sets it to 200000 when I shut it down, until I restart the computer? I looked in the Registry and it doesn't change, it's still 0. But who knows?
I have a .NET GUI application written in C# and a PDF printer. The PDF printer has a field where you can set a command to start an external application.
In this case, I can print a document with this printer and the printer starts my EXE file with the filepath to the generated PDF file as argument. How can I debug my application when it is started from the printer?
In Visual Studio 2010, I can set debug information for command line arguments, and this works fine. But if the application is started from the printer the application doesn't work fine. Therefore I want to debug my application when it is started from printer. How can I do this? Is there a parameter to start an EXE file in debug mode or something like this?
Try to attach to the process:
http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx
To attach to a running process
1.On the Debug menu, select Attach to Process. If no project is open, select
Attach to Process on the Tools menu.
2.In the Attach to Process dialog box, find the program that you want to
attach to from the Available Processes
list.
a.If the program that you want to
debug is running on another computer,
you must first select the remote
computer. For more information, see
How to: Select a Remote Machine.
b.If the process is running under a
different user account, select the
Show processes from all users check
box.
c.If you are connected through Remote
Desktop Connection, select the Show
processes in all sessions check box.
3.In the Attach to box, make sure that the type of code you will debug is
listed. The default Automatic setting
tries to determine what type of code
you want to debug. If the automatic
setting is not appropriate:
a.Click Select.
b.In the Select Code Type dialog box,
click Debug these code types and
select the types to debug.
c.Click OK.
4.Click Attach.
The Available Processes list is
displayed automatically when you open
the Processes dialog box. Processes
can start and stop in the background
while the dialog box is open. However,
the contents are not always current.
You can refresh the list at any time
to see the current list of processes
by clicking Refresh.
You can be attached to multiple
programs when you are debugging, but
only one program is active in the
debugger at any time. You can set the
active program in the Debug Location
toolbar or the Processes window. For
more information, see How to: Set the
Current Program.
All Debug menu execution commands
affect the active program. You can
break any debugged program from the
Processes dialog box or break all
attached programs from the Debug menu.
For more information, see How to:
Break Execution.
You can attach to a process when it starts using a small registry tweak.
Go to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Create a new key with the name of the executable as it will appear in Task Manager, for example, myapp.exe. Under this, create a new string value called debugger and set it to vsjitdebugger.exe.
Now, when the EXE file is triggered, a window will appear asking which debugger to attach to.
Consider adding a call into your code that explicitly requests that the debugger be attached at the current location. This has been around since Win32 days, and surfaces in .NET as System.Diagnostics.Debugger.Break (and System.Diagnostics.Debugger.Launch).
You can also add logic to decide when to trigger this if you don't want to do it the first time through:
#if DEBUG
if (++staticCounter > 3) System.Diagnostics.Debugger.Break();
#endif
And, of course, you'll want to disable it for production.
In an ASP.NET Web Site project, I've always been able to make changes to the underlying C# code and simply refresh the page in the browser and my changes would be there instantly.
I can do the same thing when working with Java and Eclipse - edit my Java source and refresh the page and my changes are there.
I cannot do this in ASP.NET MVC though and it is a real downer - I have to stop the running process and make my changes, and then restart debugging. This is a huge waste of time.
Am I doing it wrong? What is the best approach to ASP.NET MVC development?
I rarely use debug mode in ASP.NET MVC project (F5). I run the project once with CTRL+F5 and always have a browser window open. Then if I make a change to a view (.aspx, .ascx), I hit F5 in the browser and changes automatically take effect. If I have to do changes in the .NET code (controller logic, models, repositories, etc...) I no longer use the browser. To verify that my change is correct I navigate to the corresponding unit test and hit CTRL+R+T. The result is seen either in green or red.
Visual Studio locks the source code in debug mode. So your options are:
Publish the site on your local IIS and use the "attach to proccess".
Use Run without Debug (Ctrl-F5) instead and again "attach to proccess".
Break the execution in debug mode (with Breakpoint).
The first one is my favorite.
You don't have to stop the process, you can break.
Try breaking the project, then editing, then continue.
1) CTRL-ALT-BREAK
2) Edit your code
3) F5
My technique has been to launch it normally then copy the URL from the browser and open another window for the website then kill the original. Once you kill the original browser, VS lets your source code go but you still have it up in another window and can navigate it normally. Now you can edit your code and then refresh the browser and it works just like before.
The only reason to launch it normally first because VS seems to pick a random port number against localhost when firing up the built in IIS. But even that rarely changes
My URL usually looks something like this:
http://localhost:49434/something.apsx
The port numbe changes on occasion but it seems to stay the same as long as you dont close visual studio. Once you kill VS your URL will fail.
Run the MVC project with shortcut key (CTRL + F5) and now any changes you make to the C# code would be reflected in browser after refreshing (F5)
The fastest way to code is to Host locally on IIS and then all you have to do is build the solution before checking out your changes.
Another alternative is chucking everything into the App_Code folder which will compile on the fly as you make changes.
I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
How to: Enable and Disable Edit and Continue
“Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
How do I enable file editing in Visual Studio’s debug mode?
How does “Edit and continue” work in Visual Studio?
Can we edit our code while running the application
Editing C# while debugging
Thanks in advance for any help or ideas...
Mike
Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
Open the executable assembly's properties
Go to the Debug tab
Check the Enable unmanaged code debugging checkbox
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".
Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam
Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.
At the office, when I leave for the night I very rarely log off or reboot. I simply lock my workstation and go home, leaving all my development tools exactly how I left them.
If Windows-Update rolls through and reboots my machine in the middle of the night I'm only slightly peeved because when I log back in the next morning, any MS Office application, or Visual Studio instance I had running will have already automatically restarted, opening whatever file(s)/projects/solutions I may have been working on.
My question is: How can I make my Windows Forms applications (C#) do this? Is there some way for my application to "register" that it wants to be restarted if the system automatically reboots?
I think the RegisterApplicationRestart Win32 API function might be what you're after, it's part of the Restart Manager API.
If you have Windows Vista or Windows 7, you can use the Managed Restart and Recovery API. The links on that page also point to some useful blog entries
http://channel9.msdn.com/posts/DanielMoth/Windows-Vista-Restart-amp-Recovery-APIs-from-managed-code/
A simple way is to add an entry to the following registry key :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Just create a value containing the path of your app (optionally including command line arguments). The app will be run at the next startup, then the value will be deleted.
Step 1: Figure out a way to differentiate a windows-triggered restart from a standard one. One solution would be to try preprocessing messages. They're probably different for a windows-triggered restart...or at least they are in Vista in some cases :/
Step 2: If you detect it's a windows-triggered restart, add a scheduled, one-time task.