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.
Visual Studio/Team Foundation Server/.NET Framework Tooling Version
Steps to reproduce
Operating System Language