First posted to MSDN on Dec, 11 2009
In the world of app compat, sometimes you get lucky and have the app itself clearly not working, and you debug it. (Well, I guess if you’re really going to get lucky, you’ll have the app just work.) Things get murkier when an app has a bad interaction with another app, but not stand-alone (in which case you could miss the interaction until you’ve deployed to end users, since labs generally start with a clean slate). This is where the finger pointing begins – the great “blame game” where each support organization points their finger at the other one.
And, of course, the most fun is when you have an app compat problem where it makes it look like the operating system just plain doesn’t work. When you see a message like, “The network path was not found” or “File or network path no longer exists”, do you think app compat problem? No, you think you were sold a busted up old operating system. Sometimes you’re right. (We have bugs too.) Sometimes it’s your network. And, yes, sometimes it’s an app compat problem.
Such is the case for a number of support incidents we’ve seen recently with Windows Server. We debug each one, and what we found was a deadlock in srtsp.sys / srtsp64.sys. I’ve seen deadlocks all over the place – they’re one of those equal-opportunity-style bugs, because multi-threaded programming is insanely hard to do perfectly. It just so happened that these deadlocks would rather unluckily take place on the kernel mode threads servicing SMB negotiation requests.
The vendor, of course, wants happy customers, so they released a patch. If you are running older versions of Symantec Endpoint Protection 11 and Symantec Antivirus 10.2 you should get the solution from Symantec. Symantec confirms that this is a known issue and there are updates to resolve the problem. This is one of those insanely useful patches to get (as opposed to patches that fix problems that you may never see in your lifetime). See:
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007102613484948
My friend Robert put together a post on this over in the Windows Server Division Weblog
.
I’m kind of disappointed that there isn’t a disturbing amount of debugger information in the post, given who wrote it (though you’ll see there is enough to communicate the message). Robert is the kind of guy where it only takes a few minutes of watching him work to realize just how profoundly dumb you are. I had one app I was debugging once, and I was just plain stuck. (It happens.) So, I asked him for his thoughts. He dumped hex to the screen, pointed to a bit of it, said, “there’s the problem, try this fix.” And he was right. (Of course, I later realized that I was just as bad when I told my friend Gov a joke in hex, and he got it.)
