ansaurus

Question

C# based Windows Service - Tries to do JIT Debugging in production

Answer 1

+3 A:

Even though it's running as a release exe, you'll still be given the option to attach to a debugger when the app crashes... you just won't see debug symbols, just assembly :)

I believe it's the Dr. Watson process that catches app errors for debugging... Because your app is a service, Dr. Watson can't interact with the desktop, giving you the error you see. You can go to the service properties and mark "allow service to interact with the desktop", found on the LogOn tab, which should then give you a Dr. Watson popup when the app crashes.

Steps to disable Dr. Watson are here:
http://support.microsoft.com/kb/188296

If you want to debug the app on the server, you can enable remote debugging on the server, and attach Visual Studio to the process... if you want to try this, I can give you more tips for debugging a windows service remotely.

HTH, James

* Edit * Based on the code you provided, I'd look at the following areas:

Is AppSettings.Default.FTPRootPath set correctly in App.Config?
Are there changes happening to that directory immediately when the service starts? You have a timer commented as "check every five minutes", which is a little confusing, because the FileSystemWatcher will start receiving events as soon as you set EnableRaisingEvents to true. So the issue could actually lie within fileCreatedOrChanged
Along those lines, you have one BackgroundWorker servicing multiple events, and worse, you're firing the handler asynchronously. This is my most likely suspect, because if you call _worker.RunWorkerAsync() again while the first job is running, you'll get an InvalidOperationException. Though I'm not sure why you wouldn't see that in the log
You're using the timer to update the last write time for all files in the watched directory, and you do this every five seconds. This seems like a very bad idea... I'm not sure what you're trying to accomplish. This will fire your FileSystemWatcher's changed event, which would explain why you're crashing less than 10 seconds after you start (the timer's initial tick is set to fire immediately, meaning five seconds later you're changing all the file times, triggering the FileSystemWatcher multiple times shortly after that)

So my best guess is that within five seconds, you've begun firing multiple RunWorkAsync() calls on the same BackgroundWorker, which is a no-no : )

Setting the static variable _isBusy to true/false isn't reliable because you're multi-threading with the BackgroundWorkers... you need to use a Mutex or some other lock, but doesn't that really defeat the purpose of using a BackgroundWorker?

Also, if you wanted to use something like an isBusy flag, it would have to look more like:

while (_isBusy) {
    System.Threading.Thread.Sleep(5000);
}

_isBusy = true;
_worker.RunWorkerAsync(eventArgs);

You need _isBusy to be false before you try to launch the Background worker... the way you have it, if the event fires 100 times, you'll make 100 calls.

The easiest solution to your problem would be to create a new BackgroundWorker in the fileCreatedOrChanged method every time the event fires... there's overhead involved in creating so many new threads, but if the work being done in this method is significant, it will be worth the overhead.

You might be able to rely on the built-in BackgroundWorker.IsBusy property, but again, I'd have to question the benefit of asynchronous threading if you're just going to block until the background worker completes.

** Edit **

I understand now what you're trying to accomplish with the initial file timestamp changes... I think you would do better to leave the timestamps alone, but just run through a startup loop to process existing files. You can spawn a background worker thread for each one, just like you do on the FileSystemWatcher nofications. The way you're handling it is deliberately creating a side-effect to trigger the result you want.

I'm losing track a little bit in the growing complexity... the whole queue/dequeue thing might be unnecessary. Or maybe I just am not seeing a need that is truly there. Again, what strikes me is that you are launching the background worker asynchronously, then putting the main thread to sleep until it finishes.

When you put the main thread to sleep, no events will get processed, so you are truly throttling the multi-threading to one thread. I see that you want to write to the event log how long it took for a thread to finish. I will start a second answer to address that if I get a chance to, but the gist of it is to pass a Stopwatch class (which will give you an accurate count of either milliseconds or CPU ticks that pass during an operation) to the DoWorkEventArgs.Result property.

But the code you requested! Basically, wherever you decide to call _worker.RunWorkerAsync(queuedFile), rather than run one class-level BackgroundWorker create a new one each time. Pass all the same parameters for the event handlers, etc. Your service entry point would drop all the BGW references and look like:

protected override void OnStart(string[] args)
{
    try
    {
        _keys.AddRange(new string[] { "csv", "xml", "zip", "rivx" });

        _watcher = new FileSystemWatcher(AppSettings.Default.FTPRootPath, "*.*");
        _watcher.IncludeSubdirectories = true;
        _watcher.NotifyFilter = sysIO.NotifyFilters.DirectoryName | sysIO.NotifyFilters.FileName | sysIO.NotifyFilters.LastAccess | sysIO.NotifyFilters.CreationTime | sysIO.NotifyFilters.LastWrite;
        _watcher.Created += new sysIO.FileSystemEventHandler(fileCreatedOrChanged);
        _watcher.Changed += new sysIO.FileSystemEventHandler(fileCreatedOrChanged);
        _watcher.EnableRaisingEvents = true;

        WriteToEventLog("Exit Start", EventLogEntryType.Information);
    }

and the code where you run the BGW asynchronously would become:

BackgroundWorker worker = new BackgroundWorker();
worker.WorkerReportsProgress = true;
worker.WorkerSupportsCancellation = true;
worker.DoWork += new DoWorkEventHandler(BackgroundWorkerDoWork);
worker.ProgressChanged += BackgroundWorkerProgressChanged;        // Note you don't need
worker.RunWorkerCompleted += BackgroundWorkerRunWorkerCompleted;  // the 'new' here

worker.RunWorkerAsync(queuedFile);  // goes to BackgroundWorkerDoWork(object sender, DoWorkEventArgs e) //

James B 2010-10-20 16:10:56

Thanks for the information. I have extensive error handling through my app and was expecting it to write to the event logs on any and all errors! This is a headless server and does not have VS or remote debugging installed (that I am aware of). I am probably at the point where I will have to try remote debugging though I am doubtful I can ever attach as the longest it has run is 9 seconds before popping this JIT error.

Keith Barrows 2010-10-20 16:29:12

Keith Barrows 2010-10-20 16:35:14

There is a trick I use to debug a service... in the service start code, I write while(true){} as the first statement. Then, when I attach to the service, I can pause and manually set the next statement to the next line and debug from there. You'll have to increase the start timeout for the service significantly to give you time to attach.

James B 2010-10-20 16:41:45

Remote debugging can be run from the server pretty easily... you can even run it from a network share, or steps to install it as a service are here: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx

James B 2010-10-20 16:45:24

1. - Yes, AppSettings is correct. 2. - The service may start with stale files in the FTP directories. Therefore, I do an initial scan to get them to fire off the file watcher event. 3. - Would love to fire off multiple background workers, do you have any suggestions/samples? :) 4. - The timer was added as a last ditch attempt to process in stale files... I've dropped the _isBusy static variable and am now using the BackgroundWorker's IsBusy flag. This flag is set within the thread so is supposed to be safe to use. **(See edits)**

Keith Barrows 2010-10-21 22:16:24

BTW - After much Event Logging and changing the base code for the Service I finally discovered what was causing the error. Our company has a home grown Logger that was written in VB 2005 (nothing wrong with VB!). It did not have a way to pass in the target directory and instead used the Application path for the target directory. When called from the Service, the Logger was trying to write to **C:\Windows\System32!!** This directory is off limits. It seems that Windows Services treat DLLs as if they belonged there and supplies that path as the App Path. So I fixed that and now it works.

Keith Barrows 2010-10-21 22:28:32

Looking at generating a new BW for each file event raised as that is more what I want. However, when in debug mode, stepping seems to step from thread to thread quite randomly and I lose where I am at for a single file. I also want to ensure each thread is 100% compartmented so there is no bleed over between them. Just call me a thread newbie and you will be close. :)

Keith Barrows 2010-10-21 22:43:01

Debugging a multi-threaded app is a challenge!! No doubt about that. You can open the thread-window in the debugger and pick which thread you're debugging, but it's true, you will still get interrupted with every breakpoint that is hit. Debugging in this case is better left as a stop-when-you-crash exercise. Or, for debugging purposes, what I sometimes do is put in a class-level Mutex, and force my event handlers to wait on the mutex before spawning another thread.

James B 2010-10-22 00:25:35

Also, if you really want to get into multi-threading, take a look at the System.Threading.Thread class. A BackgroundWorker is packaged for easy use, but a `Thread` class gives you much more power and flexibility.

James B 2010-10-22 00:26:47

Thanks for the answer credit : ) If you want to know more about passing a stopwatch to the completed event, ask a new question and drop the link in here... this thread is getting full : ) But taking away the need to time the completion will let you drop the sleep and de-throttle your multi-threading.

James B 2010-10-22 00:32:54

Answer 2

A:

The error message tells you that it couldn't attach a debugger to let you inspect the exception. This is completely unrelated to the fact that this is a release build. Release build and debug builds can both be debugged (fortunately!).

Debugging services is a little different from debugging regular applications. Please check this guide for some advice.

Brian Rasmussen 2010-10-20 16:14:57

Thanks for the info. I checked the guide and tried to do as it says. Unfortunately, the service only ever runs for a few seconds before bailing out again so I cannot get attached.

Keith Barrows 2010-10-20 16:36:23

@Keith: Did you read the part about how to use gflags to start the service with the debugger attached?

Brian Rasmussen 2010-10-20 20:01:35

Yes I did. Our server is not setup for remote debugging and I am going through the red-tape to prove it won't wreck everything. However, I did find the cause of the problem (see comments in the accepted answer).

Keith Barrows 2010-10-21 22:24:37

@Keith: That's good to know.

Brian Rasmussen 2010-10-22 03:28:44

ansaurus

tags:

views:

answers:

C# based Windows Service - Tries to do JIT Debugging in production

related questions