Looking at the most recent crashes, there seem to be three "Buckets". **Bucket #1**: The backtrace shows us calling into Windows `EndDocImpl` which ultimately calls into a pair of DLLs with `brpri` / `breni` naming, with either a "c" or "d" suffix in the DLL name, which we don't have stack information for. e.g. `brpri19d.dll`/`breni19d.dll`: bp-b29fb62c-fe46-4a1d-b428-07e200210915 bp-948f8162-db6e-424c-8b08-151b20210921 ...and `brpri19c.dll`/breni19c.dll`: bp-0d4d25e6-b2d8-49b4-9dfd-1a3210211013 bp-c4f53805-bd1a-494b-9fe5-9504b0210926 Those ones feel like they could be a printer driver bug; though a google search for the DLL names turns up no results, which is a little surprising and means we don't know precisely where to turn. But in any case, those are harder to investigate due to the special DLL, so it may be worth setting those ones aside. **Bucket #2:** Crashes where our `GetDefaultPrinterName` function calls directly into `GetDefaultPrinterW` from `winspool.drv`, which then crashes in `DllFreeSplMem`: bp-c5cfd318-4e49-4397-825c-41f800210901 bp-b0cedf3d-721e-4f85-9ba5-ace370211002 bp-a00d6e93-8604-4dc8-bc1b-359dd0210824 bp-be2f8344-dd98-4075-aba1-6104a0210823 bp-20148520-28fd-4f10-9ded-6d0bc0210817 bp-1b41a8d1-e63f-4c13-b94b-29e200210811 **Bucket #3**: Crashes while we're showing the native print dialog (`NativeShowPrintDialog`), some varying number of stack levels deep into Windows DLLs, we ultimately hit a crash in `DllFreeSplMem` (again going through `GetDefaultPrinterW` at the innermost layer). bp-4088a5be-2c8a-47ac-94d8-00c9b0211008 (~50 stack levels of Windows APIs here) bp-0041c7c5-7578-406b-bef8-4c3f00210823 (only a few stack levels of Windows APIs here) Bucket #2 seems like the most actionable from our end at this point.
Bug 1628717 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Looking at the most recent crashes, there seem to be three "Buckets". **Bucket #1**: The backtrace shows us calling into Windows `EndDocImpl` which ultimately calls into a pair of DLLs with `brpri` / `breni` naming, with either a "c" or "d" suffix in the DLL name, which we don't have stack information for. e.g. `brpri19d.dll`/`breni19d.dll`: bp-b29fb62c-fe46-4a1d-b428-07e200210915 bp-948f8162-db6e-424c-8b08-151b20210921 ...and `brpri19c.dll`/breni19c.dll`: bp-0d4d25e6-b2d8-49b4-9dfd-1a3210211013 bp-c4f53805-bd1a-494b-9fe5-9504b0210926 Those ones feel like they could be a printer driver bug; though a google search for the DLL names turns up no results, which is a little surprising and means we don't know precisely where to turn. But in any case, those are harder to investigate due to the special DLL, so it may be worth setting those ones aside. **Bucket #2:** Crashes where our `GetDefaultPrinterName` function calls directly into `GetDefaultPrinterW` from `winspool.drv`, which then crashes in `DllFreeSplMem`: bp-c5cfd318-4e49-4397-825c-41f800210901 bp-b0cedf3d-721e-4f85-9ba5-ace370211002 bp-a00d6e93-8604-4dc8-bc1b-359dd0210824 bp-be2f8344-dd98-4075-aba1-6104a0210823 bp-20148520-28fd-4f10-9ded-6d0bc0210817 bp-1b41a8d1-e63f-4c13-b94b-29e200210811 **Bucket #3**: Crashes while we're showing the native print dialog (`NativeShowPrintDialog`), some varying number of stack levels deep into Windows DLLs, we ultimately hit a crash in `DllFreeSplMem` (again going through `GetDefaultPrinterW` at the innermost layer). I think this is the bucket that comment 0's crash report would fall into. bp-4088a5be-2c8a-47ac-94d8-00c9b0211008 (~50 stack levels of Windows APIs here) bp-0041c7c5-7578-406b-bef8-4c3f00210823 (only a few stack levels of Windows APIs here) Bucket #2 seems like the most actionable from our end at this point.
Looking at the most recent crashes, there seem to be three "Buckets". **Bucket #1**: The backtrace shows us calling into Windows `EndDocImpl` which ultimately calls into a pair of DLLs with `brpri` / `breni` naming, with either a "c" or "d" suffix in the DLL name, which we don't have stack information for. e.g. `brpri19d.dll`/`breni19d.dll`: bp-b29fb62c-fe46-4a1d-b428-07e200210915 bp-948f8162-db6e-424c-8b08-151b20210921 ...and `brpri19c.dll`/`breni19c.dll`: bp-0d4d25e6-b2d8-49b4-9dfd-1a3210211013 bp-c4f53805-bd1a-494b-9fe5-9504b0210926 Those ones feel like they could be a printer driver bug; though a google search for the DLL names turns up no results, which is a little surprising and means we don't know precisely where to turn. But in any case, those are harder to investigate due to the special DLL, so it may be worth setting those ones aside. **Bucket #2:** Crashes where our `GetDefaultPrinterName` function calls directly into `GetDefaultPrinterW` from `winspool.drv`, which then crashes in `DllFreeSplMem`: bp-c5cfd318-4e49-4397-825c-41f800210901 bp-b0cedf3d-721e-4f85-9ba5-ace370211002 bp-a00d6e93-8604-4dc8-bc1b-359dd0210824 bp-be2f8344-dd98-4075-aba1-6104a0210823 bp-20148520-28fd-4f10-9ded-6d0bc0210817 bp-1b41a8d1-e63f-4c13-b94b-29e200210811 **Bucket #3**: Crashes while we're showing the native print dialog (`NativeShowPrintDialog`), some varying number of stack levels deep into Windows DLLs, we ultimately hit a crash in `DllFreeSplMem` (again going through `GetDefaultPrinterW` at the innermost layer). I think this is the bucket that comment 0's crash report would fall into. bp-4088a5be-2c8a-47ac-94d8-00c9b0211008 (~50 stack levels of Windows APIs here) bp-0041c7c5-7578-406b-bef8-4c3f00210823 (only a few stack levels of Windows APIs here) Bucket #2 seems like the most actionable from our end at this point.