How do you diagnose a Dentrix crash step by step?
Start by classifying the crash, not by reinstalling software: a Dentrix crash that affects one workstation has a different cause set from one that affects every operatory at the same minute. Four questions sort almost every case, and each answer points to a short, ordered checklist.
The cost of guessing is chair time. The Planet DDS 2025 Dental Industry Outlook puts average production at about $3,800 per dentist per day and about $1,058 per hygienist per day, so the order of checks matters: shared faults that stop several chairs are looked at before faults that stop one.
| Question | If yes | Go to |
|---|---|---|
| Does it fail at launch, before a chart opens? | Startup dependency: printer, profile or install | Branch A |
| Does it fail on one workstation while others work? | Local cause on that machine | Branch B |
| Does it fail on every workstation together? | Shared cause: database server, network or server change | Branch C |
| Does it fail only when printing or opening images? | Print spooler or imaging bridge | Branch D |
For the ranked list of common causes behind these branches, see why Dentrix keeps crashing. This article is the decision order that sits on top of that list.
What does the Windows event log say about a Dentrix crash?
Windows records every application crash in the Application log as Event ID 1000 and every application hang as Event ID 1002, so the faulting application, faulting module and exception code are already on the workstation. Open Event Viewer, go to Windows Logs, then Application, and filter by those two Event IDs around the time of the failure.
Microsoft’s application crashing troubleshooting guidance explains that Event ID 1000 is the Windows Error Reporting record of a process that stopped unexpectedly. A faulting module named in that record is a lead, not a verdict: a common Windows module can be the victim of corruption caused earlier by another component. Reliability Monitor, opened by running perfmon /rel, shows the same crashes on a timeline next to software and update installs.
Record three things before changing anything: the time of the crash, the workstation name, and the faulting module in the Event ID 1000 entry. A faulting module that belongs to a printer driver points to Branch D, a module from security software points to the antivirus exclusions in Branch C, and a generic Windows module means the evidence is not yet enough to name a cause.
Branch A: what if Dentrix crashes at launch?
A crash at launch is almost always a startup dependency rather than the database. Dentrix can fail at startup when the Windows default printer is offline, deleted or running a damaged driver, so the default printer is the first thing to test.
Work this order: set a known-good default printer and relaunch; sign in to the workstation as a different Windows user, ideally a new local one, and launch again; then compare the Dentrix version with a workstation that works. If Dentrix launches under the new Windows profile, the original profile is the fault, and rebuilding that profile is a smaller job than reinstalling Dentrix.
Branch B: what if only one workstation crashes?
A crash that follows one workstation is local to it, so compare that machine with a working one. A fault limited to one computer cannot be the database server, because the server is serving every other workstation normally.
Check, in order: Windows Update history for installs near the first crash (Settings, Windows Update, Update history); the printer and imaging drivers installed on that machine only; the Dentrix version and workstation setup against a healthy peer; and system file integrity with sfc /scannow, which Microsoft documents for repairing damaged Windows files. If the same crash follows a user to a second workstation, the cause is the profile or the data, not the machine.
Branch C: what if every workstation crashes at once?
A fault that hits every operatory in the same minute is almost never a workstation fault. The shared parts are the Dentrix database server, the network path to it, and anything that changed on the server, so check those before touching a single workstation.
Check, in order: whether the Dentrix database server service is running on the server; free disk space on the server drive; whether the server restarted or installed updates that night; whether a backup or antivirus scan was running at the crash time; and whether the network path between workstations and server is intact. Two vendor points are worth verifying. Dentrix’s installation guidance points to configuring antivirus so the Dentrix program directory is excluded, and says client versions of Windows can serve as the database server but that the operating system’s connection limits should be evaluated, which matters when every workstation connects at once.
Match the crash time to the server’s own event log. A server event, such as a service stop or a disk warning, seconds before the workstation crashes is the strongest single piece of evidence in this branch. Slowness that grows as more chairs open Dentrix, without crashes, is a related but different problem covered in Dentrix slow with multiple users.
Branch D: what if Dentrix crashes only when printing or opening images?
If the crash is tied to one action, follow that action’s dependency. Printing depends on the Windows Print Spooler and the printer driver, and imaging depends on the sensor driver and the bridge between the imaging software and Dentrix.
For printing, a spooler that keeps stopping affects every printed output at once; see why the dental print spooler keeps stopping. For imaging, confirm Windows sees the sensor and that the imaging driver and bridge versions match, as described in sensor not detected and DEXIS or Carestream imaging not loading.
Can a Dentrix crash be seen before it happens?
Many crashes leave earlier evidence that nobody was reading, which is the practical case for monitoring. Four precursors are checkable without special tools: repeated Event ID 1000 or 1002 entries naming the same faulting module, a server drive running low on free space, backups that failed or never finished, and workstations waiting on a restart after updates.
The common thread is that a crash looks like one event to staff and like several visible signals to a monitoring tool. A monitoring tool for dental IT remote monitoring watches those signals continuously, and exit classification separates a real crash from a normal close so alerts stay meaningful; CyberCore’s exit classifier uses ten signals for that decision. How a dental-specific tool differs from a generic one is compared in dental RMM vs horizontal RMM.
Related
Frequently asked questions
Where does Windows log a Dentrix crash?
Windows writes each crash to the Application log as Event ID 1000 and each hang as Event ID 1002. Open Event Viewer, choose Windows Logs, then Application, and filter by those IDs around the failure time to see the faulting application, faulting module and exception code.
Does a crash on one computer mean the Dentrix server is at fault?
Usually not. If other workstations keep working, the database server is serving them normally, so the cause is local to the failing computer: its default printer, drivers, Windows profile, recent updates or install.
Should I reinstall Dentrix after a crash?
Reinstalling is a last resort. Identify the branch first, then test the default printer, a fresh Windows profile, the server service and recent updates. A reinstall that does not address the real cause leaves the crash in place.
Why did Dentrix start crashing after a Windows update?
Updates can replace printer or other drivers and change system components that Dentrix loads. Compare the Windows Update history with the first crash time on the affected workstation, and check whether a workstation that has not installed the same updates still works.