Question

I’m writing a solution where I use some configuration files that should be editable at runtime. I’ve been using FileSystemWatcher for this purpose before and never had much issues with it but now it’s causing a CTD on the ‘rename’ event.

This (useless) piece of code will recreate the problem in my setup:

private static int _s_renamed;
private static int _s_created;
private static int _s_errors;

private static void monitorConfiguration(string configRootFolder)
{
    var fsw = new FileSystemWatcher(configRootFolder, ConfigFilePattern)
    {
        NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName,
        IncludeSubdirectories = false
    };
    fsw.Renamed += (sender, args) => ++_s_renamed; // <-- ! CTD efter this one !
    fsw.Created += (sender, args) => ++_s_created;
    fsw.Error += (sender, args) => ++_s_errors; 
    fsw.EnableRaisingEvents = true;
}

The crash comes from FileSystemWatcher it seems. If I set a breakpoint in the event handler for FileSystemWatcher.Renamed it gets hit but the app crashes when I step out of it. If I set a breakpoint in the FileSystemWatcher.Created event handler this does not happen.

Any suggestions?

---

EDIT 1:
I’m running .NET 4 on a Windows 7 x64 (Ultimate) platform
I have seen several discussions concerning this type of problems but all has been related to people trying to update UI stuff (which must be done from the main/UI thread) from the event handlers. That’s why I just try to increment some counters in the experimental code.

Answer 1

Just to clarify:

The problem here was I had more/older consumers of the FileSystemWatcher elsewhere in my system and one of them caused an unhandled exception. The problem is the exception gets thrown in a completely different thread and caused the application to crasch to desktop. The timing fooled me into thinking it was my new consumer that somehow cause the isse but when I followed Chris Shain’s advice (see comments in the question entry) to enable break on exceptions (msdn.microsoft.com/en-us/library/d14azbfh.aspx) I immediately found the real culprit.

I would have preferred to credit Chris with the solution but he never re-posted so here it is. Hopefully we’ve learned something.

Thanks everyone and happy coding

/Jonas