This is the first time I've seen this message in Windows Mobile, but apparently it's not uncommon. I simply started up my AT&T Pure, running 6.5, and after a long pause on a totally black screen (except for the top notification and status icons), I saw an error window with options to view the details and send them to MSFT. Which I did.
I was curious, so I checked MSDN for more information on "Gwes.exe," and here's some of what I found. Enjoy!
What is GWES?
Gwes is the Graphical Windowing and
Event Subsystem. It’s one little program that draws all the controls on
the device like scrollbars, buttons, and checkboxes. It also handles
passing window messages back and forth between applications and manages
the WndProcs of all of the programs on the device that are displaying
UI.
So why does it crash all the time?
A crash
dump (“Watson dump”) is usually triggered by an unhandled exception in a
program. It packages up a callstack and some diagnostics and queues it
for transmission up to our Windows Error Reporting database.
If a
program (let’s call it test.exe) crashes inside WinMain, the exception
gets out to the unhandled exception trap in the kernel which creates the
Watson dump and then terminates test.exe.
But what if test.exe
crashes inside its WndProc? The exception travels up the callstack. The
next process up the callstack is GWES – GWES is the process that calls
each WndProc in the first place, because it’s marshalling the window
messages throughout the system.
What if GWES didn’t handle
exceptions that were thrown from your WndProc? Then any crashing WndProc
would crash GWES without fail and take down the entire system. That
doesn’t happen, so we know that’s not true. GWES handles exceptions
thrown out of other WndProcs. So GWES is responsible for triggering a
Watson dump when another program crashes in a WndProc.
The
problem is that when the Watson dump is created, it sees that GWES is at
the top of the callstack, so GWES gets the place of honor in the Watson
UI that you see in the screenshot above. We have fixed this for future
versions of the system [edit: including WM6] - crashes inside a WndProc
will show the correct process name in the "We're Sorry..." UI.
My Pure continued starting up and worked normally after the error, so it does seem to be the case that something besides Gwes.exe was the crash culprit. Still, it sounds as if the confusion was supposed to have been fixed - wonder if it has anything to do with the fact that the Pure runs a version of TouchFLO 3D, which starts up when the phone powers up...