Welcome to MSDN Blogs Sign in | Join | Help

Another interesting detail from the analysis of Windows Error Reporting data for Explorer

I was in a meeting last year where I learned an interesting tidbit of information. One of the people at the meeting was looking at the error reports submitted against Explorer, and the breakdown went something like this. For the purpose of discussion, the number of reports have been normalized into "units", the precise meaning of which is left unspecified, but is meaningful for comparison purposes.†

RankCauseUnits
1XYZ.v2 Virus6 million
2XYZ.v3 Virus5.5 million
3XYZ.v1 Virus5 million
4XYZ.v1 Virus4.5 million
5XYZ.v2 Virus4.5 million
6XYZ.v2 Virus4 million
7Bug 27182850,000

The XYZ virus (not its real name) and its variants together are responsible for the top six categories of Explorer crashes, and by an enormous margin. Seventh place, an actual bug, comes in at only 1/80th the rate of number six; if you group all the XYZ virus failures together, then the combined virus failures outnumber the most popular Explorer bug by a factor of nearly 600.

I remember reading a report that half of Explorer crashes can be directly attributable to malware. Seeing the top Explorer crash swamped by a single virus really drives that point home.‡

Footnotes

†I don't know what these units mean either.

‡The anti-malware team is very interested in this data, because when a new category of Windows crashes suddenly spikes in popularity, there's a decent chance that a new virus is on the loose.

Published Wednesday, May 21, 2008 7:00 AM by oldnewthing
Filed under:

Comments

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 10:08 AM by Nathan_works

I am curious where "poorly written shell extensions" would fall into the rankings for explorer crashes.. Given your numerous articles about how to write one, and how they are non-trivial (or at least easy to get wrong).

# patch against virus

Wednesday, May 21, 2008 10:09 AM by carl

has microsoft ever considered releasing a critical update that would block or remove these viruses? maybe some of these people without proper anti-virus software installed have automatic updates turned on.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 10:16 AM by Jonathan Wilson

Carl, isn't that what "Windows Malicious Software Removal Tool" does?

The other issue for Microsoft is that if they make the OS do too many things related to detection, removal and prevention of viruses and nasties, they are going to get hit with anti-trust complaints coming from Symantec, Mcafee etc etc for much the same reasons Netscape complained about the bundling of Internet Explorer (only more so because Netscape was free and the anti-virus vendors charge money for their products)

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 12:05 PM by Rick C

Jonathan, Netscape was only free for home use, remember?  Also, at least according to the blurb, the Windows Malicious Software Removal Tool only takes out a handful of threats, or it only lists a few.  Now, if you get this kind of disparity, where one malware causes 600x the number of crashes as the top reported bug, it's probably worth putting that in the removal tool anyway.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 12:19 PM by AndyB

I've only rarely had a crash with explorer.. now, hung to the point where I reboot is a significantly more common occurrence.

If I use task manager to kill explorer, I don't think I've ever seen the crash report dialog ask me to send info about it to MS, so I doubt the crashdump reports see many of these hung explorer problems, so I'm not surprised that the explorer crashdump stats are like they are.

[Hangs are also reported if you kill it from the Application tab of Task Manager. (The Processes tab uses TerminateProcess, and there's no way to tell whether the process was terminated as part of normal operations or because it was unresponsive.) -Raymond]

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 1:15 PM by RyanBemrose

I wonder how many Microsofties looked up that bug number before realizing that Raymond made up the number and it had nothing to do with IE crashes.

# What causes the viruses to crash explorer

Wednesday, May 21, 2008 1:17 PM by SteveL

This is interesting. Assuming that the crashes of explorer.exe are actually side-effects of the virus, and not their goal, why are they so incompetent? Or more importantly, what are they trying to do that causes the crash?

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 1:23 PM by Darrell

What would really be great is if there was a way to add a "keep me informed" option in the crash report dialog - if the crash I submitted was actually caused by virus "XYZ V2", then I'd really like to know that my computer is infected.

Of course, I'm sure this adds much more complexity to a system not really designed for that, but I could see the usefulness of such a system.  Plus, most people who would be most in need of such information would probably also be those who wouldn't use such an option ...

# bug numbers

Wednesday, May 21, 2008 1:25 PM by SteveL

RyanBemrose says "I wonder how many Microsofties looked up that bug number before realizing that Raymond made up the number and it had nothing to do with IE crashes."

Now that's the difference between open and closed source. In open source we'd create a firefox bugzilla entry with that number just for consistency, and if that wasnt enough someone would add the crash as a new firefox plugin.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 1:27 PM by Richard

@Ryan

> I wonder how many Microsofties looked up that bug number before realizing that Raymond made up

> the number and it had nothing to do with IE crashes.

If it really is the top explorer crash, that's a mighty fine coincidence. I guess the problem is the bug is unchanged under differential analysis?

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 1:29 PM by Non-TV Watcher

@RyanBemrose: Explorer, not Internet Explorer.  For Internet Explorer, I'd be surprised if the top crashes weren't: (1) Flash (2) Adobe PDF Reader.

Now you see why the press gets confused, and keeps talking about this "Microsoft Explorer Browser", or the "Microsoft Vista operating system."  On the other hand, they also talk about the "Leopard operating system" and Walt Mossberg seems to think it's some big deal that iPhone has got "the same kernel as Mac OS."

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 1:29 PM by dsn

I wonder how many noticed the bug was the constant "e".

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 1:58 PM by Joe Butler

Would it then be fair to say that, "If your Windows Explorer is crashing, it's 600 times more likely that it is due to a virus or malware than any other cause."

Opinions, anyone?

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 1:59 PM by Ulric

>What would really be great is if there was a way >to add a "keep me informed" option in the crash >report dialog

I'm under the impression that Vista has this.  it periodically checks for solutions to the problems that were logged. "Problems Reports And Solutions"

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 2:38 PM by Mark

Joe: no, because 50,000 is not the total for all other bugs.  If there were 600 other bugs, each with around 50,000 units, the odds would be even.  Besides, most people think viruses are evidence that Windows is crap.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 2:40 PM by Alexandre Grigoriev

>Would it then be fair to say that, "If your Windows Explorer is crashing, it's 600 times more likely that it is due to a virus or malware than any other cause."

>Opinions, anyone?

The only times I saw shell crashing was because of Acrobat faulty column handler. This was even causing crashes in common file open dialog. Then, again, I don't let viruses to my computer. Thus, I can classify Acrobat as malware.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 2:51 PM by Yuhong Bao

>Thus, I can classify Acrobat as malware.

I never do that.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 3:02 PM by schwiet

@Ryan

> I wonder how many Microsofties looked up that bug number before realizing that Raymond made up

> the number and it had nothing to do with IE crashes.

Given the index is less than 9 million, I think its obvious to most Windows developers they won't find this bug in their bug db.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 3:11 PM by Joe Butler

Mark,

OK, your clarification makes sense.  

So, a fair statement would instead be, "A crash in Explorer is 600 times more likely to be related to virus/malware activity than the most commonly reported Explorer bug."

Which is now true to what Raymond stated??

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 4:25 PM by James

[Hangs are also reported if you kill it from the Application tab of Task Manager. (The Processes tab uses TerminateProcess, and there's no way to tell whether the process was terminated as part of normal operations or because it was unresponsive.) -Raymond]

Useful thing to know - thanks Raymond! (I've always gone straight to the Process tab when a process has gone rogue, wishing I could generate a crash report in the process: now I'll do it this way.)

[Or just click the red X. -Raymond]

I don't know about explorer.exe, but I've caught malware doing dodgy things inside services.exe before. (More specifically, it modified winlogon.exe - but the actual work was done by spawning an instance of services.exe and modifying it in memory. Winlogon was behaving as expected, apart from having spawned a second services.exe; the cryptographic signature on services.exe was intact, but doing things it shouldn't be. Quite clever, really.) Presumably XYZ was trying to do something similar, but screwing it up badly.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 4:31 PM by John

Is Microsoft going to create an application compatibility shim to fix these broken viruses?

I am serious.  Would you rather be infected with a virus that crashes Explorer frequently or one that doesn't crash?

# Is DEP crashes reported?

Wednesday, May 21, 2008 5:24 PM by anss123

On my comp explorer dies every now and then with a "this process has been shut down because of DEP protection...." and I've never seen Vista report anything when this happens. It just restarts explorer.

Most users run with DEP off so I guess it's not statistically significant, but are those DEP errors reported?

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 5:39 PM by Alexandre Grigoriev

anss123: this is a classic symptom of failed stack-based exploit. But of a lame exploit, though; it's easy to get around DEP.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 5:51 PM by Peter

James: "Useful thing to know - thanks Raymond! (I've always gone straight to the Process tab when a process has gone rogue, wishing I could generate a crash report in the process: now I'll do it this way.)"

I do the same; straight to the Process tab. But I don't think I'll be changing, because in my experience once a process has got itself into a situation where I want to kill it (this is often Explorer; as far as I know I don't have any XYZ variants, so maybe I'm a victim of bug e*100000, who knows), it nearly never responds to whatever the Applications tab does or the 'red X'. The Process tab seems rather more effective.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 7:00 PM by Dean Harding

Peter: You've got to give the Applications tab/red "X" a little time. It starts off by trying to close the application gracefully and only resorts to more drastic measures when that doesn't work. If the application is hung, it can take a couple of seconds to figure it out...

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 7:05 PM by Neil

[if the crash I submitted was actually caused by virus "XYZ V2", then I'd really like to know that my computer is infected.]

Sadly the one time that I saw a crash caused by a virus the crash report unhelpfully suggested upgrading to a newer version. (I used the opportunity to comment on the uselessness of that particular report.)

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 7:32 PM by chrismcb

@Darrel.

Watson can do that, or at least it used to. It won't be proactive, but you can go back and look at reports you've reported. Of course this may only happen if there isn't a known cause when you reported the issue.

@Joe Butler

you can't really make a general statement from such specific data. We don't have data on the number of other crashes, or number of other viruses. Or what percentage the #1 crasher is of total crashes. Reread Raymond's last statement...

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 7:38 PM by steveg

Hmmm. Methinks Web2.0 needs something similar to this (if it hasn't happened already in some frameworks).

I'm happy to press Send when an application crashes, but I'm always disappointed there's no way to see how popular the crash is, and just in general nose around the database.

I don't expect this to change, but it'd be interesting. If anyone at MS wants to send me a spreadsheet...

# The bugs are Microsoft's fault, not the malware's

Wednesday, May 21, 2008 9:21 PM by J. Peterson

The sad thing is if the "give everybody admin access so ancient code doesn't break" Windows  "security" model was ever fixed, millions of malware induced bugs would go away and everybody's experience would be better.

Microsoft has propagated a broken security model for decades now in the name of backwards compatibility.  The viruses run wild.  It's time to realize a cure (even a painful non-compatible one) is much better than the disease.

Make a VM for the flaky old apps.  Pull the rug out from the developers and start over.  Apple did this in 2000 with OS X and reaped huge benefits.

Imagine the benefits to the entire Internet if Microsoft actually fixed Windows.  The vast majority of spam and DDOS attacks are due to malware running on Windows.  Microsoft should be held directly accountable for this.  The spammers and bot herders are merely rushing through a door Microsoft has left wide open.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Wednesday, May 21, 2008 10:10 PM by Sven Groot

J. Peterson: you might want to look at Vista, because not giving everybody admin rights is precisely what it does (provided you leave UAC on).

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 12:51 AM by Stephen Jones

When explorer hangs I use process explorer to kill the process. Others will kill it from the processes tab of task manager. As these are not reported to MS then it's no wonder the stats are so low.

Incidentally, the normal reason for explorer hanging is hardware in my experience, though you could argue it's the software's fault for letting the hardware hang it.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 1:49 AM by Erwin

I never have any problems with explorer hangs after a clean install of Windows so I've always assumed the problem lay elsewhere.

@J. Peterson

90 percent of the world's workstations are running some version of Windows, providing al large surface area for attacts and a high density for any virus to spread. I'm guessing that if 90 percent were running Linux most virussus/malware would be written for Linux.

@Darrell

I'm guessing that if Microsoft would let Windows detect which virus caused the crash and lets you know and maybe even how to remove it, they most likley be sued, since this comes close to what virus scanners do.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 2:11 AM by Drak

@Ulric:

Vista does do that, but sadly sometimes when you click 'Look for a solution' the dialog just goes away and never comes back, no matter how long you wait. It would have been nice to see a 'Sorry, no solution is available yet.'.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 2:42 AM by adrian

how can you repair the windows shell after such a thing?

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 10:00 AM by Nathan_works

I'd also add most hangs/crashes are network issues (or waiting for IO completion, say on a network file share), where I get fed up with explorer not responding to close/minimize/go away.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 10:32 AM by KenW

@J. Peterson: The actual solution to the problem is to keep people like you from posting nonsense in places where people can actually read it.

Apple could afford to totally drop backward compatibility; their user base is very small compared to that of Windows, and their users are already used to being stifled by Apple (forced to use Apple-provided hardware in order to run the OS). It's also not used for day-to-day operations in most extremely large organizations. Who cares if 10 companies complain if you're Apple and you own them anyway?

MS, on the other hand, has a very large market share, and the majority of the share of large corporate systems. Dropping backward compatibility for those customers has a much larger impact, both on those customer's revenue stream and on MS's ability to stay in business.

So please stop spreading FUD nonsense when you obviously have no clue about the subject. Thank s.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 10:59 AM by AndyC

@Drak,

Vista remembers crashes that didn't have a solution and will periodically check to see if there is any news (or you can force it by going into Problem Reports and Solutions).

There have been a few occasions when it's suddenly let me know why it crashed a few weeks prior and given me a possible solution. I think it's possibly my favourite Vista feature.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 12:52 PM by josh

"The sad thing is if the 'give everybody admin access so ancient code doesn't break' Windows  'security' model was ever fixed, millions of malware induced bugs would go away and everybody's experience would be better."

Not true.  Much of what viruses today try to do can be done without admin rights, but those writing them only test (if at all) with admin rights.  If admin rights are off by default, more viruses will be tested in that environment and rights restriction will be less effective at stopping them.

Email worms in particular should work just as well from any user account that can receive them.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 4:35 PM by steveshe

Thanks KenW, your response was much more eloquent that the "STFU moron" I was going to send if I reached the end of the comments and there were no sensible responses.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 5:29 PM by Peter

Dean: "You've got to give the Applications tab/red "X" a little time. It starts off by trying to close the application gracefully and only resorts to more drastic measures when that doesn't work. If the application is hung, it can take a couple of seconds to figure it out..."

A couple of minutes might be closer. There's that progress bar with the "end now" button, but unfortunately that doesn't always seem to work either. And I don't have that much patience, especially because the hung app is often eating a chunk of my CPU that is apparently required elsewhere.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 6:12 PM by Stefan Kanthak

@Josh: Malware running without administrative rights can just infect the current/calling users account, not the whole system.

Have you ever heard of SAFER a.k.a Software Restriction Policies?

Turn them on for all users (except administrators) and allow execution of files only in "%SystemRoot%" and below as well as "%ProgramFiles%" and below (and "%AllUsersProfile%\Start Menu" if you don't want to remove .LNK from the list of "executables").

NOW try to run a worm fetched per mail under a user account.

@KenW: So all the administrators of large corporations haven't got any clue that even not so well-written crap can be made to run under "normal users" accounts?

Stop spreading FUD!

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Thursday, May 22, 2008 8:07 PM by Mark

Stefan: but how does that stop an IE exploit from downloading the latest unpatched escalation bug?  For the last couple of years, most infections I've found were through Java (with the user clicking Allow). SAFER isn't enforced anyway.

As for admins, the majority of software conflicts with LUA on various levels.  A large business will have hundreds of applications, and virtualisation only covers a small subset of LUA bugs. Can you really expect to fix them all during an OS upgrade?

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Friday, May 23, 2008 4:52 AM by SuperKoko

John wrote:

"Would you rather be infected with a virus that crashes Explorer frequently or one that doesn't crash?"

First option, please. Frequent crashes are a useful symptom of viral infection to stop outbreak early.

@J. Peterson:

"Microsoft has propagated a broken security model for decades now in the name of backwards compatibility."

The last Microsoft Windows OS to use this "security model" is Windows Me, released eight years back from now.

Windows 2000/XP/Vista have a very fine security model with powerful access control lists and security tokens.

A few crappy (non-Microsoft) applications want write access to a subdirectory in Program Files, but, usually, it's possible to give write permissions to that subdirectory only.

The only application I've ever seen requiring admin rights is a crappy game with an integrated "firewall" supposed to "increase security".

Bad programmers happen on every system. The most used system is most affected by bad programmers.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Friday, May 23, 2008 11:36 AM by ton

My PC was infected by the TrojanDownloader.xs virus last weekend. So I'm sure I contributed to some of those numbers for Explorer crashes.  

 I think the Malicious Software Removal tool removed the virus but it didn't remove all the nasty processes left behind that keep redirecting internet explorer from the windows update page. Lately the virus isn't even letting the Error reporting service connect to the service to submit a report. It keeps resetting the connection.

*Sigh* My Pc is not in the greatest shape. Typing this from another PC now...

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Friday, May 23, 2008 4:30 PM by Alexandre Grigoriev

>My PC was infected by the TrojanDownloader.xs virus last weekend. So I'm sure I contributed to some of those numbers for Explorer crashes.  

> I think the Malicious Software Removal tool emoved the virus but it didn't remove all the nasty processes left behind that keep redirecting internet explorer from the windows update page. Lately the virus isn't even letting the Error reporting service connect to the service to submit a report. It keeps resetting the connection.

>*Sigh* My Pc is not in the greatest shape. Typing this from another PC now...

Maybe this is time to demote your (and you significant others') account to Limited User?

I did long time ago, and virus-free so far.

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Saturday, May 24, 2008 11:21 AM by Stefan Kanthak

@Mark: with the settings I proposed SAFER prevents (accidential or deliberate) execution of malware which was dropped to the filesystem (like an attachement received per mail).

It cannot prevent the execution of JScript/VBScript/<whatever code> inside any application (except that application would have an interface to SAFER and incorporate these policies; the WSH is an example). It cannot prevent any exploitation of bugs in applications or system components (which can be triggered by such simple means like <IMG SRC="http://malware.com/malicious.img"> together with the "correct" MIME type sent).

When your applications have known bugs: fix them. If there aint a fix: uninstall the application (or at least prevent it from being used).

# re: Another interesting detail from the analysis of Windows Error Reporting data for Explorer

Tuesday, May 27, 2008 10:36 AM by ton

@Alexandre you are absolutely correct and I'll be taking that precaution along with others into account in the future.

# re: Double click links wont work on Explorer

Wednesday, May 28, 2008 9:29 AM by CCTEK

Why cant I get to a link when I double click. I have to use Ctrl & Alt when I click link. Any Ideas????

# Los grandes culpables de la inestabilidad. | alt-tab

Wednesday, August 06, 2008 11:06 PM by Los grandes culpables de la inestabilidad. | alt-tab
New Comments to this post are disabled
 
Page view tracker