views:

1132

answers:

4

Hello I have a very simple windows Service that is developed in vb.net 2008. When I try to debug it by going to tools-> Attach to process though I see my service it is disabled and Type of Managed and I cannot select the process.

How do I debug my service?

Thanks

A: 

A service is nothing more than a console app so you should be able to run the exe from the command line as long as it was compiled in debug mode. Once the process is running from the command line you would then go to Debug => attach to process in visual studio and attach to the exe you just fired up from the command line. You could also run within the Visual Studio IDE directly with F5.

If your service is running under a special user account you will need to use the runas /user command either to fire up visual studio if you are debugging in visual studio or from the command line if you are running it from the command line.

If this does not work.... let me know.

Best Regards, Michael

Michael Mann
+1  A: 

Are you sure you are looking at your actual service process? Check the service name -- is it something like servicename.vshost.exe? If so, then that is not your service but a visual studio hosting process used for F5 debugging (among other things).

To debug your service select the "show processes from all users" checkbox. You should see the actual service process, servicename.exe, in the process list. If it is visible then just attach to that process.

Tuzo
Yes Tuzo I see only servicename.vshost.exe and not the vshost.exe. where do you think is the issue
Ignore any process with vshost.exe in it since you can't debug those. Did you check "show processes from all users"? If you did you should see your service process as servicename.exe. If you don't see it there, then it probably means your service is not started. Try starting the service.
Tuzo
+3  A: 

Attaching to the service should work, so I'm not sure why you can't. In lieu of that, insert the following line in the application entry point for your Windows service (or the OnStart() method), compile in debug mode, and start the service.

System.Diagnostics.Debugger.Break();

When you start the service, you will be prompted to debug the process. Select the Visual Studio 2008 debugger, and the process will load and stop at your programmatic breakpoint. Hit F5 to start running again.

EDIT:

Let's say that you've built the service (release mode or debug mode - it doesn't matter) and used installutil to install the service, but you haven't started it yet. As long as the service is not running, you can continue to make code changes and re-compile. When you start the service, your service will reflect your latest code changes. If the service is running, you will not be able to fully compile the service because the exe/dll(s) are in use and cannot be replaced. Obviously, simply stop the service, re-compile, and then re-start the service. The point is this: You do not have to uninstall the service in order to modify the code. Just stop it, change the code, re-compile, and re-start.

As for debugging in debug vs. release mode, I don't know if that's why you can't attach to the process. I do know that it is possible to debug release versions, but I would not recommend this simply because if optimizations are turned on, you may run into issues traversing the code. We've only used release-mode debugging as a last resort.

By default, when you build a Visual Studio application in debug mode, it is put in a bin\Debug subdirectory of your project. When you build in release mode, the executable is put in a bin\Release subdirectory. When you use installutil to install your service, the only thing that matters is where the service resides. In your case, I would suggest un-installing the release-mode version of your service (installutil /u c:\myapp\myapp\bin\release\myapp.exe), putting the programmatic breakpoint in, building the debug version, and then using installutil to install the debug version (from the bin\Debug directory).

Sorry this was long-winded. I hope that's clear.

Matt Davis
Thanks Matt. I have one question. Here is what I did. I build the application in release mode. went to install util and installed it with something like installutil c:\myapp\myapp\bin\release\myapp.exeDo you mean I should have built it in debug mode and then useinstallutil c:\myapp\myapp\bin\debug\myapp.exe and then try to attach to the process?
Yes, you should build in debug mode and install from the bin\debug folder.
Tuzo
+2  A: 

If you follow the basic Windows Service creation "tutorial" in MSDN, you will run into this. You will see MyNewService.vshost.exe in the Attach To Process dialog, but it will be disabled. To see your service, you must check BOTH "Show Processes From All Users" AND "Show Processes In All Sessions" to see your service. The service is running under the "SYSTEM" user name, if you followed the instructions in the tutorial, and services generally run in a different session.

Once you check both of those boxes (and ignore the MyNewService.vshost.exe), you will see MyNewService.exe, which you will be able to select and debug.

Of course, nothing will happen until the service hits a breakpoint. You can create the OnPause (like the OnContinue) handler, but in order to be able to pause your service, you will need to set the CanPauseAndContinue flag on your service (the same object as the AutoLog flag).

Also, in my testing on my 64 bit machine, merely re-compiling the project did not allow successful debugging. Even compiling and re-installing did not work. I had to re-compile the project, then re-compile the setup project, and then re-install the setup in order to be able to debug the service.

Finally, the Event Log can be viewed through the Event Viewer, under Administrative Tools in the Control Panel. The "MyNewLog" is located under Applications and Services Logs, when created as described in the MSDN tutorial.

James Nachbar, www.plastic.org

James Nachbar