Windows 10: Mystery COM Surrogate crashes

Does anyone at all have any good suggestions on troubleshooting these?

I seem to be getting these at random times, with no rhyme or reason. The faulting module is quite often, but not always mso20win32client.dll, but I've seen mso30win32client.dll once, or none indicated at all. The crashes can appear right after a restart, but sometimes they happen hours later when the machine is idle, doing nothing in particular at all. These events have started to appear a few weeks back, and the only system changes that occurred right before this started was an automatic Office 365 update.

I am unable so far to correlate the crashes with any particular activity or program running on the machine, and I do not notice any lack of functionality before or after the crashes. I went through the task manager log, and I checked if I could correlate the crashes with other messages in the event viewer, with no success. They also happen infrequently: I can go up to three or even four days without issue, only to see one of these pop up again in my event viewer. I have never seen more than two of them a day.

So, does anybody have any suggestions as to how I might identify the culprit?

P.S.: And please, for the love of god, don't suggest running the system file checker. In all my years of Windows computing I have never, ever seen a single problem, nor have I found any evidence on the internet of non-catastrophic problems like this being linked to corrupt system files. All cases I have ever heard of or seen where sfc found anything were related to systems that had been completely hosed, either by the user or through obvious hardware failures...

:)

 

Com surrogate consumes all the memory memory

Hi,

The dllhost.exe process goes by the name COM Surrogate and the only time you're likely even to notice its existence is when it crashes and you get the message COM Surrogate has stopped working. What is this COM Surrogate and
why does it keep crashing?

The COM Surrogate is a fancy name for Sacrificial process for a COM object that is run outside of the process that requested it. Explorer uses the COM Surrogate when extracting thumbnails, for example. If you go to a folder with thumbnails enabled,
Explorer will fire off a COM Surrogate and use it to compute the thumbnails for the documents in the folder. It does this because Explorer has learned not to trust thumbnail extractors; they have a poor track record for stability. Explorer has decided to absorb
the performance penalty in exchange for the improved reliability resulting in moving these dodgy bits of code out of the main Explorer process. When the thumbnail extractor crashes, the crash destroys the COM Surrogate process instead of Explorer.

In other words, the COM Surrogate is the I don't feel good about this code, so I'm going to ask COM to host it in another process. That way, if it crashes, it's the COM Surrogate sacrificial process that crashes instead of me process. And when it
crashes, it just means that Explorer's worst fears were realized.

In practice, if you get these types of crashes when browsing folders containing video or media files, the problem is most likely a flaky codec.

chk the link

What does the COM Surrogate do and why does it always stop working?

Try creating a new user account and check in it

 

2 COM Surrogate running in Task Manager

Here's a short and relatively understandable Microsoft Developer blog article from 2009 discussing the COM Surrogate. The quote following below is from the article.

What does the COM Surrogate do and why does it always stop working?

"The COM Surrogate is a fancy name for Sacrificial process for a COM object that is run outside of the process that requested it. Explorer uses the COM Surrogate when extracting thumbnails, for example. If you go to a folder with thumbnails enabled,
Explorer will fire off a COM Surrogate and use it to compute the thumbnails for the documents in the folder. It does this because Explorer has learned not to trust thumbnail extractors; they have a poor track record for stability. Explorer has decided to absorb
the performance penalty in exchange for the improved reliability resulting in moving these dodgy bits of code out of the main Explorer process. When the thumbnail extractor crashes, the crash destroys the COM Surrogate process instead of Explorer."

If you think about this excerpt, it's reasonable to believe that if an instance of a COM Surrogate were to crash and another were to be started in its place, there'd quite possibly appear to be two of these temporarily displayed in Task Manager since we
often see other processes come and go with some lag.

The other clearly possible situation is simply that more than one COM Surrogate has been requested based upon the other processes you've been using which cause this to be invoked. If you were to do two things in close succession which Explorer or some other
key Windows process determines might be risky to system stability, the COM surrogate may be invoked by more than one of these.

The primary thing to understand is that the COM Surrogate itself is being invoked in order to protect an operating system process such as Explorer from potentially crashing itself, so seeing these is a good thing regardless of what might be causing them
to be displayed.

Rob

 

That problem is related to Office. Helps to know what version that you have, along with have you tried going in Programs and Features, to do a repair? Have you tried doing a search and read those posts to try the fixes listed.

 

Like I said, Office 365, which gets continuous updates to the latest version of everything. So, essentially Office 2016.
Repair does nothing. I'm not even sure it's Office that's the culprit; this is Windows we are talking about, everything could be linked to anything...

 

Hmm, that is the brand name, not the actual version that it is going by. If you look at your list of updates and noticed that the problems started when the last set of updates happened, you go in and uninstall those updates and the problem magically goes away.

Everyone that has dealt with Microsoft's products since the first day they pushed MSDos out, knows that they have a tendency to screw things up royally. That is why people make backups, make sure that System Restore is on and that there are restore points made to allow you to roll back out of a bad update to something.

The problem is again with 365, not with Windows 10, if you did a search for that filename. You want to blame Windows, that is fine. Those who know better, are going to point fingers at a bad update for once again, which is Office.