Our software uses a FileSystemWatcher. At a customer of our's, the watcher's listener systematically raises the following exception (caught through AppDomain.CurrentDomain.UnhandledException):
System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path)
at System.IO.Path.GetFileName(String path)
at System.IO.FileSystemWatcher.MatchPattern(String relativePath)
at System.IO.FileSystemWatcher.NotifyFileSystemEventArgs(Int32 action, String name)
at System.IO.FileSystemWatcher.CompletionStatusChanged(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* overlappedPointer)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
I found out that the FILE_NOTIFY_INFORMATION structures received (and probably sent by their network file server which I know nothing about) are malformed: the FileNameLength includes the terminating null character, which, I guess, ends up in the path processed by CheckInvalidPathChars.
This is definitely a bug of the file server, but I think it wouldn't hurt if the file system watcher was a bit defensive with respect to the contents of the notifications. It's a very painful problem, because there is no way to catch the exception: it occurs in a filesystemwatcher listener called directly by .NET's guts. When we catch it in AppDomain.UnhandledException, all we can do is pop up a message explaining that our app is going to close.