Hi @Thomas Müller , Thank you for the detailed follow-up and for separating the unrelated crashes. The corrected 6/3 split across three workstations still indicates a repeatable print-stack failure.

The new evidence does not identify Microsoft IPP Class Driver as the cause. The HP queue uses an HP v3 driver, and the presence of IppCommon.dll, WSD data, or queue names only confirms that related components and queues were enumerated. It does not show which queue triggered the crash. A PSA also cannot be fully excluded because it may run out of process.

The duplicate Brother queue is a useful lead, but not yet proof of the root cause. Please test on one affected workstation:

1. Set Microsoft Print to PDF as default and retest.
2. Remove both Brother queues, reboot, recreate one clean queue, and retest.
3. If it continues, temporarily remove the HP queue.
4. Test another application using the classic print dialog or, if possible, a minimal x86 PrintDlgEx program.

Please note whether any new crash matches either existing signature. If it remains reproducible, collect a full user-mode dump, as this may provide the COM object, heap, and register state needed to investigate the invalid pointer.

The Microsoft Print to PDF and clean Brother queue results will be the most useful next information. Please remove sensitive information before sharing diagnostics.

Hi @Thomas Müller ,

Just checking in to see if you had a chance to review my previous response. Please feel free to reach out if you have any questions - I’m here to help.  

Thanks for the detailed analysis and the test plan.

First, a correction to my own numbers. I had only looked at part of the dump set when I wrote the
original post. Going through all of it, the collection is 16 dumps from 4 workstations rather than
15 from 3. Nine of them are the print-stack crashes, and those nine do come from 3 workstations, so
that part of my report stands. Of the remaining seven, five turned out to be a re-entrancy bug in
our own code and one is a heap corruption we are still looking into; one could not be resolved. We
have identified and are fixing our own two, so I am not trying to attribute the whole set to
Windows.

I also need to correct the "identical in 7 of 9" statement. There are two distinct top signatures,
six and three:

    Windows_Graphics_Printing!UnifiedPrintDialogHandler::OnPrintTaskRequested+0xc4      (6 dumps)

    combase!...InternalAddRef
    combase!CGIPTable::RegisterInterfaceInGlobal
    Windows_Graphics_Printing!PrintTaskServer::RuntimeClassInitialize+0x204             (3 dumps)

In the second group the instruction pointer is already invalid, so the top frame is a raw address
and the resolved chain below it is identical in all three. Both signatures occur on more than one
machine.

On your first question, whether the machines share a printer: two devices are installed on all the
affected workstations, an HP LaserJet M14-M17 and a Brother HL-L5100DN. One or both appear in the
memory of nearly every print dump. I have to add a caveat though. The print dialog enumerates all
installed queues when it opens, so a queue name in a dump only proves it was installed, not that it
was the target of the job. I cannot tell from these dumps which queue was the default.

On your second question. The HP queue uses an HP-supplied v3 driver, the .gpd file is
hppclms_14-17.gpd under the usual spool drivers directory, so that one is not going through the
Microsoft IPP Class Driver. The string "Microsoft IPP Class Driver" does appear in one dump, and
IppCommon.dll is loaded in all nine print dumps. There are also WSD device entries, and they differ
from machine to machine.

As for a Print Support App: I checked the loaded module list of each of the nine crashing processes
for anything under the WindowsApps directory and found nothing in any of them. That only rules out a
PSA component inside our own process, of course, since a PSA runs separately, so it does not rule
out a PSA being involved further down the print stack.

Firmware versions are not in the dumps. I will read them off the devices and post them.

Your third question, whether the crash stops with Microsoft Print to PDF as the default, I have not
been able to test yet. That has to happen on the customer site and I will run exactly the sequence
you described and report back.

One thing that may be relevant to your point about queue state. On the workstation with the most
crashes, the Brother queue exists twice, the second one with the "(Copy 1)" suffix that Windows adds
when a device that is already present gets installed again. That looks like the kind of leftover
queue state you suggested checking, so removing and recreating that queue will be part of the test.

We still have all 16 original dumps, the matching PDB files and the exact application build, and the
application binaries have not changed since these crashes, so the symbol resolution can be
reproduced at any time.

Sorry for the delay, but the my last response caused an ACCOUNT LOCK, somehow the guard identified my text as an violation of the rules of conduct

Hi @Thomas Müller ,

I am sorry that your earlier detailed response became unavailable after the account lock, so I could not review or answer that version. I also apologize for the delay, as I was unavailable over the weekend.

Thank you for reposting it and for carefully separating the six and three print-stack signatures.

I also agree with your important qualification: a queue name found in a dump proves that the queue was installed or enumerated, not that it was the selected printer.

The evidence confirms a repeatable failure while Windows is initializing the print dialog, but it does not yet identify Microsoft IPP Class Driver as the root cause. The most useful lead at present is the shared printer environment, particularly the duplicate Brother queue on the workstation with the highest crash count.

Recommended isolation and workaround

Please test on that workstation, stopping after each stage if the result changes.

1. Set Microsoft Print to PDF as the default printer.
2. Restart the application and repeat the print-dialog operation.
3. If the crash no longer occurs, stop there and report that result before changing any queues.

This provides an immediate workaround if it is stable. If the dialog opens reliably, users may then try selecting the physical printer, but this must be verified because the crash may occur while all queues are being enumerated, before a printer is selected.

If Microsoft Print to PDF does not resolve the problem:

1. Remove both Brother queues, including (Copy 1).
2. Restart Windows.
3. Install one clean Brother queue using the latest supported Brother driver and printer firmware.
4. Retest before making any other change.

If it still crashes, temporarily remove the HP queue and test once more.

The results can be interpreted as follows:

• Rebuilding the Brother queue resolves it: Continue using the single clean queue and leave the duplicate removed.
• Removing the HP queue resolves it: Recreate the HP queue and update or reinstall its v3 driver.
• Microsoft Print to PDF works, but one or more physical queues trigger the crash: Focus on queue state, driver components, firmware, and printer capability data.
• Microsoft Print to PDF also crashes: The problem is broader than one physical printer queue and should proceed to dump analysis.

One application comparison

If the issue remains, please test one other Win32 application that uses the classic print dialog, or preferably a minimal x86 program calling PrintDlgEx.

• If the second application also crashes, Qt and your application become substantially less likely to be required for the failure.
• If only your application crashes, we should compare its print-dialog initialization and investigate whether the previously identified heap corruption can occur before printing.

This distinction is especially important because an invalid instruction or vtable pointer can result either from the print path itself or from earlier process memory corruption.

Full dump only if the issue remains

For unattended customer-site collection, I recommend Windows Error Reporting LocalDumps first. From an elevated command prompt, replace YourApplication.exe with the actual executable name:

mkdir C:\Dumps

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourApplication.exe" ^
/v DumpFolder /t REG_EXPAND_SZ /d "C:\Dumps" /f

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourApplication.exe" ^
/v DumpCount /t REG_DWORD /d 5 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourApplication.exe" ^
/v DumpType /t REG_DWORD /d 2 /f

DumpType = 2 requests a full user-mode dump. Microsoft documents these per-application LocalDumps settings, including DumpFolder, DumpCount, and DumpType.

collecting-user-mode-dumps

One limitation is relevant here: WER LocalDumps may not capture the failure if the application installs its own custom crash-reporting mechanism or intercepts the exception. Since your application already has crash logging, please confirm whether it installs an unhandled-exception filter or writes its own dumps.

If WER does not produce a dump, ProcDump can be used as the fallback:

procdump.exe -accepteula -ma -e 1 -w YourApplication.exe C:\Dumps

Here, -e 1 also monitors first-chance exceptions. This can capture exceptions that are subsequently handled, but it may also generate a dump for an unrelated first-chance exception, so the timestamp and exception code should be correlated with the observed printing crash.

procdump

Information needed in your next update

Only these results are needed initially:

1. Does Microsoft Print to PDF prevent the crash?
2. Does removing both Brother queues and creating one clean queue prevent it?
3. If not, does temporarily removing the HP queue change the result?
4. Can another application using the classic print dialog reproduce it?
5. Are the three affected workstations on the same Windows build and cumulative-update level?