Our Windows Error Reporting runtime module seems to be notified of all
sorts of non-fatal exceptions. Since there is no documentation clarifying
how to tell them apart from actual crashes we'll try using the bIsFatal
field in the WER_RUNTIME_EXCEPTION_INFORMATION structure for this
purpose. There is no documentation describing the contents of the field
so we can only assume that what its name implies is what we're looking
for.
Differential Revision: https://phabricator.services.mozilla.com/D118813
This patch adds a new field to the structures that WER reads from a
crashed process. This field contains a pointer to the global variable
that records the size of the last failed annotation.
When WER intercepts a crash it will use this address to read the
variable. If it's not zero it will add the corresponding annotation
to the crash report.
Depends on D116449
Differential Revision: https://phabricator.services.mozilla.com/D116450
Since this added the new flag to the crash ping I also took the time to update
the crash ping documentation with all the flags that have been added and
removed over the last few versions of Firefox.
Depends on D115380
Differential Revision: https://phabricator.services.mozilla.com/D116017
This also notifies the main process after the minidump has been generated.
I refactored the code a bit so the patch is probably larger than it should be
but the code should be a bit more readable overall.
With this change the minidump generation flow works like this:
- When the callback gets invoked in the WER process we read the structure that
is stored in every process' to figure out if it's the main process or a child
one. This is done by reading said process' memory, the pointer has been
passed to the runtime exception module when it was registered.
- If the main process crashed everything works like it used to.
- If it was a child process then we first capture a minidump of it.
- Then we read the structure representing it in the main process:
WindowsErrorReportingData. The address of this structure was passed into the
child process' command-line so we need to parse that first, then we read it
from the main process memory.
- We fill the structure and write it back into the main process memory.
- At this point if everything went fine we create a new thread in the main
process just to execute the WerNotifyProc function that will inform the main
process to the presence of the new minidump.
There's one important tidbit that's worth keeping in mind: the synchronization
between the main process and the WER process is implicit. The
WindowsErrorReportingData structure in the main process is kept alive until the
child process dies, the main process will destroy it only after that point. As
long as we're in the runtime exception module the crashed process is kept alive
so this will prevent the main process from touching that structure.
We explicitly terminate the crashed process **after** we're done with the
structure so nothing bad could happen... unless someone makes a change to
Gecko that breaks the previous assumption.
Another important thing to keep in mind: we wait for the newly created thread
to inform the main process but only for 5 seconds. We don't want to wait
indefinitely because the function that we're calling is taking a lock and if
it blocks for some reason WER will get stuck waiting for it, so it will never
kill the crashed process which in turn will prevent the main process from
moving ahead. In principle this should never happen but better be safe than
sorry.
Depends on D115379
Differential Revision: https://phabricator.services.mozilla.com/D115380
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
This patch adds a new field to the structures that WER reads from a
crashed process. This field contains a pointer to the global variable
that records the size of the last failed annotation.
When WER intercepts a crash it will use this address to read the
variable. If it's not zero it will add the corresponding annotation
to the crash report.
Depends on D116449
Differential Revision: https://phabricator.services.mozilla.com/D116450
Since this added the new flag to the crash ping I also took the time to update
the crash ping documentation with all the flags that have been added and
removed over the last few versions of Firefox.
Depends on D115380
Differential Revision: https://phabricator.services.mozilla.com/D116017
This also notifies the main process after the minidump has been generated.
I refactored the code a bit so the patch is probably larger than it should be
but the code should be a bit more readable overall.
With this change the minidump generation flow works like this:
- When the callback gets invoked in the WER process we read the structure that
is stored in every process' to figure out if it's the main process or a child
one. This is done by reading said process' memory, the pointer has been
passed to the runtime exception module when it was registered.
- If the main process crashed everything works like it used to.
- If it was a child process then we first capture a minidump of it.
- Then we read the structure representing it in the main process:
WindowsErrorReportingData. The address of this structure was passed into the
child process' command-line so we need to parse that first, then we read it
from the main process memory.
- We fill the structure and write it back into the main process memory.
- At this point if everything went fine we create a new thread in the main
process just to execute the WerNotifyProc function that will inform the main
process to the presence of the new minidump.
There's one important tidbit that's worth keeping in mind: the synchronization
between the main process and the WER process is implicit. The
WindowsErrorReportingData structure in the main process is kept alive until the
child process dies, the main process will destroy it only after that point. As
long as we're in the runtime exception module the crashed process is kept alive
so this will prevent the main process from touching that structure.
We explicitly terminate the crashed process **after** we're done with the
structure so nothing bad could happen... unless someone makes a change to
Gecko that breaks the previous assumption.
Another important thing to keep in mind: we wait for the newly created thread
to inform the main process but only for 5 seconds. We don't want to wait
indefinitely because the function that we're calling is taking a lock and if
it blocks for some reason WER will get stuck waiting for it, so it will never
kill the crashed process which in turn will prevent the main process from
moving ahead. In principle this should never happen but better be safe than
sorry.
Depends on D115379
Differential Revision: https://phabricator.services.mozilla.com/D115380
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
This patch adds a new field to the structures that WER reads from a
crashed process. This field contains a pointer to the global variable
that records the size of the last failed annotation.
When WER intercepts a crash it will use this address to read the
variable. If it's not zero it will add the corresponding annotation
to the crash report.
Depends on D116449
Differential Revision: https://phabricator.services.mozilla.com/D116450
Since this added the new flag to the crash ping I also took the time to update
the crash ping documentation with all the flags that have been added and
removed over the last few versions of Firefox.
Depends on D115380
Differential Revision: https://phabricator.services.mozilla.com/D116017
This also notifies the main process after the minidump has been generated.
I refactored the code a bit so the patch is probably larger than it should be
but the code should be a bit more readable overall.
With this change the minidump generation flow works like this:
- When the callback gets invoked in the WER process we read the structure that
is stored in every process' to figure out if it's the main process or a child
one. This is done by reading said process' memory, the pointer has been
passed to the runtime exception module when it was registered.
- If the main process crashed everything works like it used to.
- If it was a child process then we first capture a minidump of it.
- Then we read the structure representing it in the main process:
WindowsErrorReportingData. The address of this structure was passed into the
child process' command-line so we need to parse that first, then we read it
from the main process memory.
- We fill the structure and write it back into the main process memory.
- At this point if everything went fine we create a new thread in the main
process just to execute the WerNotifyProc function that will inform the main
process to the presence of the new minidump.
There's one important tidbit that's worth keeping in mind: the synchronization
between the main process and the WER process is implicit. The
WindowsErrorReportingData structure in the main process is kept alive until the
child process dies, the main process will destroy it only after that point. As
long as we're in the runtime exception module the crashed process is kept alive
so this will prevent the main process from touching that structure.
We explicitly terminate the crashed process **after** we're done with the
structure so nothing bad could happen... unless someone makes a change to
Gecko that breaks the previous assumption.
Another important thing to keep in mind: we wait for the newly created thread
to inform the main process but only for 5 seconds. We don't want to wait
indefinitely because the function that we're calling is taking a lock and if
it blocks for some reason WER will get stuck waiting for it, so it will never
kill the crashed process which in turn will prevent the main process from
moving ahead. In principle this should never happen but better be safe than
sorry.
Depends on D115379
Differential Revision: https://phabricator.services.mozilla.com/D115380
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
- Move the decision logic for Win32k Lockdown to a common area where it can
be re-used
- Cache the Win32k Lockdown state, since the result will never change
- Add IDL to allow JavaScript to query it
- Add it to the "about:support" page
- Add an annotation to Crash Reporter after the first time it's read
Differential Revision: https://phabricator.services.mozilla.com/D114850
- Move the decision logic for Win32k Lockdown to a common area where it can
be re-used
- Cache the Win32k Lockdown state, since the result will never change
- Add IDL to allow JavaScript to query it
- Add it to the "about:support" page
- Add an annotation to Crash Reporter after the first time it's read
Differential Revision: https://phabricator.services.mozilla.com/D114850
The brower process used WMI to add BIOS Manufacturer and MemoryErrorCorrection
annotations to a crash report. The downside is that calling `IWbemLocator::ConnectServer`
loads all of the registered AMSI modules into the process. As we don't actively use either
of the annotations now, this patch removes WMI code to improve the stability.
Differential Revision: https://phabricator.services.mozilla.com/D115334
This should help investigate bug 1613798.
In particular, this should show if the profiler is taking too long to serialize its profile buffer, or something else is happening afterwards (whether the profiler is running or not).
Differential Revision: https://phabricator.services.mozilla.com/D111786
This patch changes a few things regarding how error codes are printed out.
First of all it updates the list of statuses defined in ntstatus.h, and makes
it up-to-date with the current Windows SDK. With this done we change how we
print out a minidump exception code so that if it's not among the known
EXCEPTION_* values we try to print it out as a STATUS_* one.
It's worth noting that the EXCEPTION_* definitions are just aliaeses for
STATUS_* ones and deprecated in Windows but since they're commonly used we
just keep them.
Last but not least we change how EXCEPTION_BOUNDS_EXCEEDED,
EXCEPTION_STACK_BUFFER_OVERRUN and EXCEPTION_HEAP_CORRUPTION are
printed because they are inconsistent with their Windows equivalents.
They're "breakpadisms" and they've caused confusion in the past.
Differential Revision: https://phabricator.services.mozilla.com/D111712
This patch changes a few things regarding how error codes are printed out.
First of all it updates the list of statuses defined in ntstatus.h, and makes
it up-to-date with the current Windows SDK. With this done we change how we
print out a minidump exception code so that if it's not among the known
EXCEPTION_* values we try to print it out as a STATUS_* one.
It's worth noting that the EXCEPTION_* definitions are just aliaeses for
STATUS_* ones and deprecated in Windows but since they're commonly used we
just keep them.
Last but not least we change how EXCEPTION_BOUNDS_EXCEEDED,
EXCEPTION_STACK_BUFFER_OVERRUN and EXCEPTION_HEAP_CORRUPTION are
printed because they are inconsistent with their Windows equivalents.
They're "breakpadisms" and they've caused confusion in the past.
Differential Revision: https://phabricator.services.mozilla.com/D111712
Gabriele Svelto
Emilio Cobos Álvarez
Valentin Gosu
Christoph Kerschbaumer
Mitchell Hentges
Iulian Moraru
surajeet310
Brindusan Cristian
Chris Martin
Csoregi Natalia
Alexandre Lissy
Mike Hommey
Toshihito Kikuchi
Jeff Muizelaar
Andi-Bogdan Postelnicu
Steven Michaud
Alexandre Lissy
Joel Maher
Steve Fink
Gerald Squelart
smolnar