Sure, too many changes at once, this is a firehose problem. You've already increased the buffer size to the maximum allowed, Windows doesn't allow a bigger one. It is allocated in "precious" memory, the kernel memory pool.
This could be a highly active file server, but much more commonly this is caused by a problem in your code. You don't drink from the firehose fast enough. It is imperative that your event handlers return as quickly as possible so that the buffer is emptied fast enough and can keep up with the rate of changes on the file server.
That's very often fumbled, a typical implementation does something unwise like copying the file, reading it, looping until the file can get opened. Expensive things, the looping bug is a very common mistake, a file is very rarely usable when the event fires because whatever app that changes the file still has it opened. There's no upper limit either on how long it can keep a lock on the file. Clearly that will always cause a buffer overflow.
So a properly implemented FileSystemWatcher event handler does nothing but quickly put the passed file path into a thread-safe queue and does nothing else, that never ought to take more than a microsecond. And uses another thread to try to empty that queue again, dealing with the likelihood that the file can't be opened yet.