Skip to content
LogoTradeline Consulting
Back to Blog

QuickBooks Enterprise Crashes When Switching to a Redirected Printer on an RDP Server (Fixed)

•Tradeline Consulting
QuickBooks Enterprise Crashes When Switching to a Redirected Printer on an RDP Server (Fixed)

If you run QuickBooks Enterprise on a Remote Desktop (RDP) server, you may have hit this one: a user opens Printer Setup or tries to print, switches to their redirected printer, and QuickBooks vanishes. No error dialog, no recovery prompt. The application is just gone.

We recently worked through this exact crash on a client's terminal server, and the diagnosis is a good example of why reading the right log matters. Here is the full walkthrough, from symptom to root cause to fix, so you can resolve it on your own server.

The symptom

  • QuickBooks Enterprise (in our case, version 24.0) running on an RDP session host
  • The user switches to a printer redirected from their local machine, the ones named like HP LaserJet (redirected 2)
  • QuickBooks closes instantly

The company file was fine, multi-user mode was fine, and QuickBooks reopened normally afterward. Only the printer switch triggered the crash.

Why QBWin.log will not show you the answer

The first instinct is to open QBWin.log, the main QuickBooks diagnostic log. We did, and it showed a completely healthy startup: database engine running, company file opened, file update completed.

It also showed two entries that look alarming but are red herrings:

  • LVL_SEVERE_ERROR--MainFrame must be already created by now as this dll is demand loaded appears in virtually every QBWin.log at startup and is harmless noise.
  • Connection Error: Invalid user ID or password with error -6069 just means someone mistyped their QuickBooks password at the login screen.

When QuickBooks dies hard enough that Windows terminates the process, the crash never makes it into QuickBooks' own log. The evidence lives in the Windows Event Log instead.

Finding the real crash record

On the server, open PowerShell and pull the application crash events:

Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000; StartTime=(Get-Date).AddDays(-1)} |
  Where-Object { $_.Message -match 'QBW' } |
  Select-Object -First 3 -ExpandProperty Message

You can also find the same record in Event Viewer under Windows Logs > Application, Event ID 1000, source "Application Error", faulting application qbw.exe.

In our case the record looked like this:

Faulting application name: qbw.exe
Faulting module name: ntdll.dll
Exception code: 0xc0000374

Two details here tell the whole story:

  • Exception code 0xc0000374 means STATUS_HEAP_CORRUPTION. Something wrote past the end of a memory buffer inside the QuickBooks process.
  • ntdll.dll is where the corruption was detected, not what caused it. Windows validates the heap, finds the damage, and terminates the process on the spot. That is why there is no error dialog.

The root cause: stale printer settings in QBPRINT.QBP

QuickBooks stores per-form printer settings in a file called QBPRINT.QBP. Each entry contains a serialized copy of the printer's settings block (the DEVMODE structure), keyed by printer name.

On a terminal server this design ages badly:

  • Redirected printer names change on every reconnect. (redirected 2) becomes (redirected 5) the next session.
  • The driver behind a redirected printer can change too, between Remote Desktop Easy Print and the native driver, or across driver updates.
  • QBPRINT.QBP is shared by every user on the server, so stale entries accumulate fast.

When QuickBooks loads a stored settings block and the printer's current driver expects a different-sized structure, the driver writes past the buffer QuickBooks allocated. That is the heap corruption, and the crash follows immediately.

The fix

  1. Have every user log out of QuickBooks on the server. The settings file is shared across all sessions, so this matters.
  2. Browse to C:\ProgramData\Intuit\QuickBooks Enterprise Solutions 24.0\ (adjust for your version; ProgramData is a hidden folder).
  3. Rename two files:
    • QBPRINT.QBP to QBPRINT.QBP.old
    • wpr.ini to wpr.ini.old
  4. Relaunch QuickBooks, open File > Printer Setup, and reselect your printer.

QuickBooks rebuilds both files cleanly, without the stale settings blocks that were corrupting memory. Renaming instead of deleting means you can roll back if needed.

The only side effect: per-form printer customizations (margins, template printer assignments) reset and need to be selected once more.

This resolved the crash for our client on the first try.

If the crash comes back

If a clean QBPRINT.QBP still crashes, the driver itself is producing a bad settings block every time rather than replaying a stale one. Check which driver the redirected printer is using:

Get-Printer | Format-List Name, DriverName

Then align the drivers one of two ways:

  • Native vendor driver crashing? Force Easy Print via Group Policy: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Printer Redirection > "Use Remote Desktop Easy Print printer driver first" = Enabled.
  • Easy Print crashing? Install the printer's native x64 driver on the server so redirection binds to it instead.

One more tip: keep printer names on client machines short. QuickBooks has a long history of misbehaving with printer names much over 32 characters, and the (redirected N) suffix eats into that limit.

Keeping QuickBooks healthy on a terminal server

A few habits prevent most printer-related instability on RDP hosts:

  • Rebuild QBPRINT.QBP and wpr.ini during maintenance windows if printing behavior gets strange
  • Standardize on one redirection driver strategy (Easy Print or native) instead of mixing both
  • Keep client printer names short and consistent
  • Check Event Viewer for Event ID 1000 before restarting anything, so you fix causes instead of symptoms

Need help with QuickBooks issues or integrations?

We work with QuickBooks Desktop and Enterprise environments every day, from crash diagnosis like this one to inventory management, order management, and warehouse automation built on top of QuickBooks.

If your business needs custom QuickBooks integrations, terminal server troubleshooting, or an operational layer that QuickBooks alone cannot provide, contact our team. We are happy to help you get to a root cause instead of living with workarounds.

Return to Blog