Crash report: https://crash-stats.mozilla.org/report/index/a0e12c47-cbee-4e23-8298-15abf0240228

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  winspool.drv  PdcRegenerationCache::GetPrintPdcRegenStatus  
1  winspool.drv  PdcRegenerationHandler::RegeneratePdcForPrinter  
2  winspool.drv  RegeneratePrintDeviceCapabilities  
3  Windows.Graphics.Printing.dll  Windows::Graphics::Printing::OptionDetails::PrintTaskOptionDetailsServer::PrintTaskOptionsServerTransaction::_CallRegeneratePrintDeviceCapabilitiesForIpp  
4  Windows.Graphics.Printing.dll  Windows::Graphics::Printing::OptionDetails::PrintTaskOptionDetailsServer::PrintTaskOptionsServerTransaction::BindPrinter  
5  Windows.Graphics.Printing.dll  Windows::Graphics::Printing::PrintTaskServer::PrintTaskServerPriv::BindPrinter  
6  rpcrt4.dll  Invoke  
7  rpcrt4.dll  ?Ndr64StubWorker@@YAJPEAX0PEAU_RPC_MESSAGE@@PEAU_MIDL_SERVER_INFO_@@PEBQ6AJXZPEAU_MIDL_SYNTAX_INFO@@PEAK@Z  
8  rpcrt4.dll  NdrStubCall3  
9  combase.dll  CStdStubBuffer_Invoke  onecore\com\combase\ndr\ndrole\stub.cxx:1479

Looking at the user comments, several of them mention that this is with the system print dialog, and in particular the crash happened after they hit Cancel when the print job was taking a while.

Quoting:

Was attempting to print a pdf. The connection wasn't working so I hit cancel, which is when firefox crashed

Was trying to print a pdf through the system dialog. I got a popup that said to wait for a system connection to the printer or something. Didn't seem to be doing anything, so I hit cancel, then firefox crashed.

Had a pdf open. Went to print using system print dialog (windows). Problem communicating with the printer so hit cancel and then ok at the dialog summarizing the problem. Crash.

Tried to print and canceled out

This happened during an attempt to print using a system dialog.

Several of the comments mention a network or WiFi printer, too.

It looks like the crashes started in November; but also, some of them are from very old Firefox/Thunderbird versions like 102.15.1 and 102.1.0esr.

So this may not be a regression from a change that we made, but rather some sort of behavior change in Windows or in some printer driver(s).

The severity field is not set for this bug.
:tlouw, could you have a look please?

For more information, please visit BugBot documentation.

I'm taking a look here, FWIW... I'm trying to reproduce the crash based on the observations that I made above, but so far I've been unable to reproduce.

Right now I'm testing with two Windows 11 machines; the first is sharing a printer, and the second is using that shared printer. I have Firefox set up with that printer as the last-remembered-print-target, so that we'll try to pull up the print settings for that printer as soon as you try to print.

If I disconnect the first Windows machine from the network, and then start Firefox on the second machine and attempt to print, then our print dialog spins its throbber for a minute or two, which is bad/interesting. Worse: if I try to go directly to the system print dialog with print.prefer_system_dialog:true, then Firefox as-a-whole hangs (and is unresponsive) for a minute or two while we wait for the system print dialog to appear. I was able to trigger a similar issue in Chrome, though, so I'm not sure to-what-extent we should consider this our bug vs. a bug/annoyance in the Windows print APIs.

I haven't yet been able to reproduce any crashes, though. I also haven't managed to see any popups about printer communication trouble like the ones mentioned in the user reports in comment 1 (and I think a popup like that might need to appear in order for me to trigger the crash, based on those user comments).

I'm going to tentatively triage this as S3. At this point, it's not clear it's even our bug, or a bug we can do anything about (the crash is deep in the Windows print APIs -- Mozilla DLLs barely appear in the backtraces of the crashes I've looked at -- e.g. bp-8ba6353f-0849-455a-8bcd-01a050231209, bp-6212e1fa-4f24-4194-bcc4-d1f530240319, bp-a0e12c47-cbee-4e23-8298-15abf0240228). Whatever nullptr is being tripped in there is likely out of our control. And per comment 2, the timeline suggests that this was introduced via an update to some other piece of software (not sure if that'd be a Windows update or a print driver or something else).