Brave Tech World

November 17, 2006

FRI 17 NOV 2006

Visual C# Express can't attach to a processs. By Marcelo

 

    I'm not sure if I'm doing something wrong here, but yesterday I installed Visual C# Express in one of my productions machine to debug a problem with a process.

 

    If you don't know, VC# Express is the free version of Visual Studio C#. It has less menus, less options, less things, but from the description it seemed good enough for what I needed.

 

    All that I needed was to attach to our SampaService process (a Windows Service) to see if it why it was hanging midway a schedule job. It seemed obvious to me that VC# Express would allow me to attach and debug a process. But the menu is not there!

 

    So far, I came to the conclusion that you don't have that option on VC# Express, which is ridiculous. I'm not going to buy a license and install Visual Studio in production. It is too much money and too much work for many machines. I just want to debug a process once in a while.

 

    Does anybody know another way to do that? Does WinDbg can debug C#?

 

 

FRI 17 NOV 2006

Bloggers Blogging about Bloggers and Blogging By Marcelo

 

    Why every blogger feels the need to analyse bloggers, blogs and blogging? Just because you write or read a blog doesn't make you an expert.

 

FRI 17 NOV 2006

Make your Windows Service run like a regular process. By Marcelo

 

    When I worked on Exchange 2000, my component was called ADC (Active Directory Connector). It was a Windows Service like most component on Exchange Server. If you ever worked with Windows Service you know they can be a pain in the butt to debug. Mostly when you're trying to debug the initialization code.

 

    We had two tricks to debug our component, that I managed to replicate in C# (that component was Win32/C++). First, we had a workaround to make the service run like a Windows Console process. You just entered the EXE name and it would run on the console. You could even start debugging it directly from Visual Studio with F5. The second trick was when you need to make sure it would work under the correct account. When you run from the console you are running on your User name (you could impersonate but that is a different topic). So, what we did was to add a 30 second delay right at the beginning of "Main" to allow time for us to attach the debugger. This was not a persistent thing, meaning, we only compiled with that Sleep if we need to debug the initialization code running under the Exchange service account.

 

    Well, I manage to get the first trick (run as Windows Console app) working on C#.

string user = Environment.UserName;
if(String.Compare(user, "System", true)==0
    || String.Compare(user, "Network Service", true)==0)
{
    ServiceBase[] ServicesToRun;
    ServicesToRun = new ServiceBase[] { new MainService() };
    ServiceBase.Run(ServicesToRun);
}
else
{
    // Invoke your service here
}

    The simple idea is to verify if the account is running under Local System or Network Service (the most probable accounts you'll run a Windows Service). The alternate method would be to pass some arguments on the command line to the process.

 

 

FRI 17 NOV 2006

Still using DBMON? Try DebugView. By Marcelo

 

    I was... Until today. I just found out about DebugView (a.k.a. DbgView) that you can download from SysInternals, which is a pretty cool set of tools from Microsoft.

 

    Thanks Vasco for the great tip.