Moving the code that is responsible for dumping other processes to a fully dedicated process -- which is already planned -- should allow us to discriminate between the two possibilities here: - if this is a bug within our (or Microsoft's) crash dump code, we would see the same crash reports as currently; - if this crash is the consequence of simultaneous corruptions affecting the child and main processes, this specific crash should disappear. When we implement the dedicated crash dumping process, we should have it block injection of all third-party DLLs to limit the risk of simultaneous corruptions affecting all our processes including the crash dumping one. An example scenario would be a third-party application injecting its DLL into all our processes and sending to all its in-process clients a message that results in a heap corruption.
Bug 1799225 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Moving the code that is responsible for dumping other processes to a fully dedicated process -- which is already planned -- should allow us to discriminate between the two possibilities here: - if this is a bug within our crash dump code or Microsoft's `MiniDumpWriteDump`, we would see the same crash reports as currently; - if this crash is the consequence of simultaneous corruptions affecting the child and main processes, this specific crash should disappear, and we should manage to generate crash dumps for all corruptions. When we implement the dedicated crash dumping process, we should have it block injection of all third-party DLLs to limit the risk of simultaneous corruptions affecting all our processes including the crash dumping one. An example scenario would be a third-party application injecting its DLL into all our processes and sending to all its in-process clients a message that results in a heap corruption.
Moving the code that is responsible for dumping other processes to a fully dedicated process -- which is already planned -- should allow us to discriminate between the two possibilities here: - if this is a real bug within our crash dump code or Microsoft's `MiniDumpWriteDump`, we would see the same crash reports as currently; - if this crash is just the consequence of simultaneous corruptions affecting the child and main processes, this specific crash should disappear, and we should manage to generate crash dumps for all corruptions. When we implement the dedicated crash dumping process, we should have it block injection of all third-party DLLs to limit the risk of simultaneous corruptions affecting all our processes including the crash dumping one. An example scenario would be a third-party application injecting its DLL into all our processes and sending to all its in-process clients a message that results in a heap corruption.
Moving the code that is responsible for dumping other processes (including the main process) to a fully dedicated process -- which is already planned -- should allow us to discriminate between the two possibilities here: - if this is a real bug within our crash dump code or Microsoft's `MiniDumpWriteDump`, we would see the same crash reports as currently; - if this crash is just the consequence of simultaneous corruptions affecting the child and main processes, this specific crash should disappear, and we should manage to generate crash dumps for all corruptions. When we implement the dedicated crash dumping process, we should have it block injection of all third-party DLLs to limit the risk of simultaneous corruptions affecting all our processes including the crash dumping one. An example scenario would be a third-party application injecting its DLL into all our processes and sending to all its in-process clients a message that results in a heap corruption.
Moving the code that is responsible for dumping other processes (including the main process) to a fully dedicated process should allow us to discriminate between the two possibilities here: - if this is a real bug within our crash dump code or Microsoft's `MiniDumpWriteDump`, we would see the same crash reports as currently; - if this crash is just the consequence of simultaneous corruptions affecting the child and main processes, this specific crash should disappear, and we should manage to generate crash dumps for all corruptions. When we implement the dedicated crash dumping process, we should have it block injection of all third-party DLLs to limit the risk of simultaneous corruptions affecting all our processes including the crash dumping one. An example scenario would be a third-party application injecting its DLL into all our processes and sending to all its in-process clients a message that results in a heap corruption.