Since I installed CIS 4 (public ver.) verclsid.exe keeps run in the sandbox. In the pop-ups I ordered not to run this application again in the sandbox but the alerts keep say that it runs in the sandbox. From what I understand from the internet this application is connected to security shell or something like that. I should be safe.
I putted it in my own safe applications but it didn’t help.
Actually I’m wondering if it would be enough to leave the sandbox active and then restart your computer. I’m thinking that maybe telling the sandbox to never run it in the sandbox only applies the next time the application is run.
I’m trying to figure out how it works myself. Hopefully we’ll get some answers soon.
Sorry you are having these problems. You can try defining it as an installer rather than a safe file. Sometimes this works.
Can you find out what is ‘calling’ verclsid? If a sandboxed file is calling it it will be sandboxed. You can find this out by using sysinternals process explorer (just google these 3 words). Double click on the verclsid line in process explorer to find its parent.
I HOPE U FIND SOME USEFUL INFORMATION!..IN THE FOLLOWING ARTICLE…
:Last year, a Windows security update got a lot of flack for causing some machines to hang, and it was my fault. (This makes messing up a demo at the Financial Analysts Meeting look like small potatoes.)
The security fix addressed a category of attacks wherein people could construct shortcut files or other items which specified a CLSID that was never intended to be used as a shell extension. As we saw earlier, lots of people mess up IUnknown::QueryInterface, and if you pass the CLSID of one of these buggy implementations, Explorer would dutifully create it and try to use it, and then bad things would happen. The object might crash or hang or even corrupt memory and keep running (sort of).
To protect against buggy shell extensions, Explorer was modified to use a helper program called VERCLSID.EXE whose job was to be the “guinea pig” and host the shell extension and do some preliminary sniffing around to make sure the shell extension passed some basic functionality tests before letting it run loose in Explorer. That way, if the shell extension went crazy, the victim would be the verclsid.exe process and not the main Explorer process.
The verclsid.exe program created a watchdog thread: If the preliminary sniffing took too long, the watchdog assumed that the shell extension was hung and the watchdog told Explorer, “Don’t use this shell extension.”
I was one of the people brought in to study this new behavior, poke holes in its design, poke holes in its implementation, review every line of code that changed and make sure that it did exactly what it was supposed to do without introducing any new bugs along the way. We found some issues, testers found some other issues, and all the while, the clock was ticking since this was a security patch and people enjoy mocking Microsoft over how long it takes to put a security patch together.
The patch went out, and reports started coming in that machines were hanging. How could that be? We created a watchdog thread specifically to catch the buggy shell extensions that hung; why isn’t the watchdog thread doing its job?
That was a long set-up for today’s lesson.
After running its sanity tests, the verclsid.exe program releases the shell extension, un-initializes COM, and then calls ExitProcess with a special exit code that means, “All tests passed.” If you read yesterday’s installment, you already know where I messed up.
The DLL that implemented the shell extension created a worker thread, so it did an extra LoadLibrary on itself so that it wouldn’t get unloaded when COM freed it as part of CoUninitialize tear-down. When the DLL got its DLL_PROCESS_DETACH, it shut down its worker thread by the common technique of setting a “clean up now” event that the worker thread listened for, and then waiting for the worker thread to respond with a “Okay, I’m all done” event.
But recall that the first stage in process exit is the termination of all threads other than the one that called ExitProcess. That means that the DLL’s worker thread no longer exists. After setting the event to tell the (nonexistent) thread to clean up, it then waited for the (nonexistent) thread to say that it was done. And since there was nobody around listening for the clean-up event, the “all done” event never got set. The DLL hung in its DLL_PROCESS_DETACH.
Why didn’t our watchdog thread save us? Because the watchdog thread got killed too!
Now, the root cause for all this was a buggy shell extension that did bad things in its DLL_PROCESS_DETACH, but blaming the shell extension misses the point. After all, it was the fact that there existed buggy shell extensions that created the need for the verclsid.exe program in the first place.
Welcome Slashdot readers. Since you won’t read the existing comments before posting your own, I’ll float some of the more significant ones here.
The buggy shell extension was included with a printer driver for a printer that is no longer manufactured. Good luck finding one of those in your test suite.
The security update was recalled and reissued in a single action, which most people would call an update or refresh, but the word recall works better in a title.
Published Friday, May 04, 2007 7:00 AM by oldnewthing
Filed under: Code
Ray you deserve some respect
Friday, May 04, 2007 10:24 AM by Nathan
For accepting responsibility in this. Nice job. Something we can all learn from.
Friday, May 04, 2007 10:39 AM by charless
Ditto to Nathan’s comment!
But, the question that came to my mind was why didn’t anyone see/report this hang durring internal testing? Based on what you have said over the last few days, this hang seems to fall somewhere between likely and very likely. Or maybe a better question would be, now that you have explained why this design “can’t” work, can you explain how verclsid.exe ever exits cleanly?
And again, thankyou for some very insigtful reading!
[A few days of internal testing is not going to come anywhere near 100% coverage of all shell extensions on the planet. It takes only one bad program to foul an upgrade. -Raymond]
Friday, May 04, 2007 11:02 AM by tony roth
I love it when somebody else screws up!
How to manually add a DLL to the allow list
Friday, May 04, 2007 11:14 AM by stanley
I learned the hard way when I was creating a shell extension recently that verclsid.exe will not allow Explorer to load your DLL if you haven’t finished implementing the interfaces you say you implement.
During development, it may be helpful to manually add your shell extension to the allow list:
That’s kind of a hackish approach, and you’ve got to make sure to remove the entry before you deploy to make sure your final DLL will get verclsid’s blessing. Is there a better way to do this?
I almost wanted to ask if the suite of tests verclsid runs is published anywhere, but I imagine Microsoft would rather leave it unspecified so as not to imply a contract. It does make it a little frustrating to try and figure out why verclsid.exe won’t let Explorer load your DLL, though.
Friday, May 04, 2007 11:37 AM by tcliu
Interesting story, Raymond.
One question though: I get the impression that a shortcut can specify any CLSID, and Explorer will try to load it as an extension. The problem was that some CLSIDs referred to objects that were never intended to be used as shell extensions, and therefore Explorer would crash.
Now, verclsid.exe will catch the currently existing ones, but is there any way to mark a COM object as “Under no circumstances use this as a shell extension”? I’ve searched around a bit, but didn’t find anything. (I’ve never written a COM object in my life, so I don’t even know where to start.)
Friday, May 04, 2007 12:34 PM by Adam
Just out of curiosity, how did explorer and verclsid.exe communicate?
It’s just that the way to do this that springs to my mind would be for explorer to launch verclsid.exe, and have explorer wait for verclsid.exe to exit and check its exit status. If verclsid.exe exits indicating success within the time limit that explorer is willing to wait for, all is OK. If it returns indicating a failure, or crashes, or doesn’t exit within the time limit, the CLSID is bad.
So, I guess I’m wondering why exit codes weren’t adequate for the communication that was needed (what else apart from yes/no is there?), and what communication mechanism was used instead.
I’m also wondering what would happen if a buggy/malicious extension managed to scribble over the part of the address space being used by the watchdog thread. Was it just assumed that having the watchdog in the same process as the thing you’re testing for its ability to trash a process was too tiny a risk to worry about?
Friday, May 04, 2007 1:01 PM by charless
Oops, I misinterpreted in sentence that starts: “The DLL that hosted the shell extension…” Thanks for the clairification. Now the end of the story makes sense too.
Friday, May 04, 2007 1:29 PM by Fred Schtiener
Looks like the classic case of bad testing, not that I haven’t done but just pointing out the obvious. I know you can’t test for every possible case (sometimes) but still you need more testing. Then rinse and repeat.
[More testing = more time = more people complaining that Microsoft is slow to release patches. You can’t have everything. The bug was in a shell extension that came with a particular model of printer that the manufacturer doesn’t even make any more! Good luck testing that. -Raymond]
Friday, May 04, 2007 3:19 PM by JamesNT
Excellent article. I seem to recall being bitten myself by said patch. Regardless, you are still my programming god. The only thing this situation proves is that you are human and, like the rest of us, are expected to work magic half the time.
Thank you for all your hard work.
Friday, May 04, 2007 3:38 PM by dislyxec
Integrity and Honesty, a microsoft core value
I love these stories–it reminds us all that we’re not the only ones that ■■■■■ up
Friday, May 04, 2007 3:50 PM by Brody
This article reminded me of how it feels to wade through the kludged-up tangle of anti-pollution hoses and devices on a 1972 Ford Pinto. Those Pintos would only work if everything was adjusted perfectly. There were too many complex interdependencies for mere mortals to grasp. If Raymond Chen can’t even predict how something will work, something tells me the design is way too complex in the first place.
Friday, May 04, 2007 4:23 PM by Nick
So after all this time it was YOU!
Friday, May 04, 2007 4:36 PM by Cody
You’re about to be Slashdotted.
Friday, May 04, 2007 5:06 PM by Doug Harrison
When the DLL got its DLL_PROCESS_DETACH, it shut down its worker thread by the common technique of setting a “clean up now” event that the worker thread listened for, and then waiting for the worker thread to respond with a “Okay, I’m all done” event.<
Why didn’t you just wait on the thread handle? I think this would have avoided the hang. That said, I think this is more the duty of the main program, and I’d try to avoid doing this in DLL_PROCESS_DETACH. In general, the problem with an “all done” event is that the thread continues to run after setting it, so it isn’t really “all done”. This becomes more and more of a problem as the distance between the raw API and the abstraction you’re using increases, e.g. CreateThread vs. _beginthreadex vs. AfxBeginThread.
[You’ll have to ask the author of the buggy shell extension, but I suspect the answer would be “Because that guarantees a deadlock.” -Raymond]
Friday, May 04, 2007 5:16 PM by Aaron
Like charless, I was a little confused as to how the process exit procedure got tripped up. (caveat: I’m not a windows developer) The procedure is listed as:
releases the shell extension
From “the first stage in process exit is the termination of all threads other than the one that called ExitProcess.” I deduce that step 3 is reached, and the shell extension worker thread is NOT shut down at this point due to COM “unloading” because the extension did a double LoadLibrary. When step 3 proceeds, the worker thread is prematurely terminated (with respect to its own shutdown protocol) and therefore the extension hangs.
If that’s all correct, then it sounds like the hole here is just that proper shutdown should have been included in the behavior checking/testing.
I can see how that could be overlooked (especially if the problem you are trying to detect in code in the Real World is not during shutdown). Although I assume it would still be worthwhile to implement, because every once in a while somebody will want to log off, shut down explorer, whatever, and that’s when such bad behavior would bite them (although maybe not so clearer associable with explorer).
Very interesting. I am a beginning programmer, and just learned a ton about threads. But if I can see the explorer.exe process in taskmgr, why can’t I see verclsid.exe? (I have all the XP updates as of this morning.)
verclsid.exe is a temporary process that starts when needed, then exits shortly afterward. You’ll only see it in taskmgr if you happen to be watching the instant explorer wants to load a new shell extension and asks verclsid to test it first.
verclsid.exe is not trying to run anymore (don’t know why). Also, I don’t see it in my system32 folder anymore (I think it created sometimes and disappears so CIS can’t load it into My Own Safe Files.
I think Mayur said something about it.
If the file has disappeared from system32 it is puzzling and a bit worrying, there have been some other reports of the sandbox ‘disappearing’ files.
I can get verclsid.exe to be invoked by opening an internet drive mapped into Windows explorer by Idrive (www.Idrive.com), but it is not sandboxed. Verclsid.exe is in my case is invoked by Windows Explorer. You can catch it running in process explorer and double click on it, but you have to be quick.
In your system it’s a patched or infected or unsigned version of verclsid
Verclsid is being called by a sandboxed file
CIMA has looked at verclsid since your problem, determined it safe, and communicated this to all CIS installations.
If verclsid turns out still to be in system32 try:
Running an AV scan as a precaution. Quarantine it if AV reports concerns.
Opening a drive mapped into explorer by an explorer extension, and catching and double clicking on verclsid.exe to see what is calling it.
That should give some info for the developers to address the bug.
as soon as it was found, verclsid.exe started to run (SandBox pop-up). On every pop-up I said not to run this file again in the SandBox (like 4-5 times). when I clicked on the file name in the pop-up it was not found (look in the screenshot). I think that because the file was not found so CIS can not load it in My own safe files.
Also, there was no program that ran into the sandbox in that time, so the parent is maybe explorer.exe.
I didn’t understand what to do from your post, can you explain it to me please?
I have also seen (and reported) that CIS sandboxes nonexistent files. Here is a bug report by another user.
Strange that you found verclsid.exe in My Own Safe Files (if you have the file or not). CIS should say that the file is already safe, if you try to add it. Have you removed Microsoft Windows Component Publisher from My Trusted Software Vendors? Or perhaps your verclsid.exe (if you have/had it 88)) has been modified. :-\ If you click on Purge, is verclsid.exe removed from My Own Safe Files?
You can run sigverif.exe (it’s in system32 folder) to verify that all system files are digitally signed.
Using explorer right click on verclsid.exe and choose ‘scan with comodo antivirus’. If result is positive quarantine it and report back
If result is negative in CIS navigate to Defence+ ~‘My safe software vendors’ ~ Add ~ Read from a signed executable. Then select verclsid.exe. Report back exactly how CIS responds - a screen shot would be great.
This should give us enough info to determine if this is a bug or malware or OS malfunction, and thus suggest further action.
(Thanks to Jowa for his ideas - 2) is basically sigverif via an easier route!)
I didn’t remove Microsoft Windows Component Publisher.
You will not believe this but when I wanted to see if verclsid.exe will be removed if I click on Purge, verclsid.exe was not there anymore.
But, it was there after the Sandbox alerted me today (see previous post).
C:\WINDOWS\SoftwareDistribution\Download is an update folder for Windows Update. verclsid.exe in that folder might be corrupt or the wrong version (if that is possible). Can you check its properties and tell us what version you have. I have XPS SP3, and the file version is 5.1.2600.5512 (xpsp.080413-2105). According to your signature, you have XP SP2. Is it fully updated? Do you have a Windows XP SP2 CD to copy verclsid.exe from? Or maybe you should download SP3…
Did sigverif.exe scan C:\WINDOWS\ and its subfolders? You can make sure it does, if you click on Advanced.
I have the same as version as you have, however I need to say something about that.
one year ago, when I wanted to play GTA IV, it didn’t want to run under sp2, so to fix it was or to download sp3 or to chenge the sp version in the registry. I think that after I did that windows update downloaded updates for sp3. I thought it will make problems but my PC run OK so I didn’t care.
I rescan with your instructions and it found 7678 unsigned files and 58 files that not scanned it found verclsid.exe-…pf (look in the screenshot).