QuickBooks Error C=387 -- Damaged Transactions List Repair

Error C=387 signals a damaged transactions list in your company file; our engineers walk through verify, rebuild, and deeper repair steps to restore it.

QuickBooks Desktop error C=387 is one of the older C-series codes that still surfaces in company files maintained across many version years. It points to structural damage in the transactions list — the internal index QuickBooks uses to locate and link every entry in your file. When that index breaks, the program halts to protect data integrity. The good news is that the built-in Verify and Rebuild utilities resolve the majority of cases, and the remaining files respond well to targeted list repair.

What the error message says

The message typically appears as one of these variants:

• "Error Code C=387" — displayed in a dialog with the text "QuickBooks has encountered a problem and needs to close."
• "QuickBooks encountered a serious error. Error code = C=387." — sometimes followed by additional text referencing the transactions list or a specific internal table.
• In some cases the error appears as a crash to desktop with no dialog at all, and C=387 shows up only in the QBW.INI log or the Windows Application Event Log.

What the code means

C=387 specifically indicates that QuickBooks detected corruption in the transactions list structure. The transactions list is not the same as the register you see on screen; it is the underlying database index that tracks every transaction record — invoices, bills, checks, journal entries, and all others — and their relationships to customer, vendor, and account records. When one or more entries in that index are missing, duplicated, or cross-linked incorrectly, QuickBooks cannot reliably read or write data and throws C=387 to prevent further damage.

What triggers it

The most common triggers our engineers see are:

1. Improper shutdown — power loss, a forced quit, or a Windows crash while QuickBooks is mid-write.
2. Network interruption — a dropped connection between a workstation and the server hosting the .QBW file over a mapped drive or network share.
3. File size growth — company files that have grown very large over many years are more prone to index fragmentation and list corruption.
4. Storage sector errors — bad sectors on the hard drive where the company file or its transaction log (.TLG) resides.
5. Version-year upgrades on an already-stressed file — upgrading a file with latent minor damage can surface C=387 when the new version's stricter validation catches what the old version tolerated.

How to fix it

Our engineers recommend working through these scenarios in order, starting with the most common resolution.

Scenario 1: Run Verify and Rebuild (resolves most cases)

1. Open QuickBooks in single-user mode. If the file is hosted, switch the host to single-user mode as well.
2. From the File menu, choose Utilities, then Verify Data.
3. If Verify reports "Your data has lost integrity," note the specific message but proceed to Rebuild regardless.
4. From File > Utilities, choose Rebuild Data.
5. When prompted, let QuickBooks create a backup before rebuilding — do not skip this step.
6. Allow Rebuild to run to completion without interrupting it, even if it appears to hang. Large files can take an extended period.
7. After Rebuild finishes, run Verify Data a second time. If it now reports no problems, open a few recent transactions and confirm they display correctly.
8. If Verify still reports damage after a second Rebuild cycle, move to Scenario 2.

Scenario 2: Identify and repair the specific damaged transaction

1. After Verify fails, look at the QBWin.log file. Press F2 on the keyboard to open the Product Information window, then press F3 to open the Tech Help window. Go to the Open File tab and select Open QBWin.log.
2. Scroll to the bottom of the log and look for lines containing "VERIFY:" or "LVL_ERROR." These lines often reference a specific transaction number or a list element.
3. Note the transaction type and date if the log provides them, then locate that transaction in QuickBooks.
4. Delete and re-enter the damaged transaction if you can identify it with certainty. If the transaction is reconciled, note the original details first so you can re-enter it identically.
5. Run Verify Data again.

Scenario 3: The file will not stay open long enough to run Verify

1. Hold down the Ctrl key while double-clicking the QuickBooks desktop icon to open the application with no company file loaded.
2. From the No Company Open window, select your company file but do not open it yet.
3. Hold Alt and click Open. Keep holding Alt until the file fully opens. This suppresses many background processes that can trigger the crash.
4. If the file opens, immediately switch to single-user mode and run Verify and Rebuild as described in Scenario 1.
5. If the file still crashes on open, restore your most recent good backup (.QBB) and run Verify on the restored copy to confirm it is clean before continuing work.

Scenario 4: Damage persists after all above steps

If Verify continues to report damage after two Rebuild cycles and you cannot isolate the offending transaction from the log, the transactions list damage is too deep for the built-in utilities. At that point the file requires targeted list-level repair using our file repair service, which rebuilds the damaged index structures directly.

How to prevent it recurring

• Always close QuickBooks through the File > Close Company and File > Exit path rather than clicking the window X or shutting down Windows with the file open.
• On network installations, ensure workstations map the server drive with Reconnect at sign-in enabled and that the connection is stable; intermittent drops during writes are a leading cause of index corruption.
• Run Verify Data in single-user mode on a regular schedule — weekly for active multi-user environments. Verify is non-destructive and catches low-level damage before it escalates to a C=387 halt.
• Keep at least three rotating backups and store at least one copy on different physical media.
• If the company file has grown large, consider a SuperCondense or File Optimization to reduce the transaction volume the index must manage.