Exception 0xC0000005 is the Windows access-violation code: the panel's HMI runtime read, wrote or executed at an invalid memory address and was shut down. The code names the failure class, never the trigger, so photograph the message, log the active screen, the last touch and the communications state before you restart, and change one variable per test if it returns.
A panel dies mid-shift with Fatal Application Error, a runtime executable name, Exception: 0xC0000005 and a hex address. The temptation is to restart, shrug and move on. The code has a documented meaning: it is the Windows access-violation exception, raised when an application touches memory the operating system never gave it. What the message does not carry is the trigger, the screen, the action or the wire behind it. This page explains what the code tells you, what to photograph and write down before a restart erases the state, and how to isolate the cause with one change per test if the error comes back.
What does exception 0xC0000005 mean on an HMI panel?
Exception 0xC0000005 is the Windows access-violation code. The panel's runtime application tried to read from, write to, or execute code at a memory address the operating system would not give it, so the operating system shut that application down. The operating system's own documentation defines it as an exception raised when an application reads, writes or executes an invalid memory address. Read, write and execute are the only three ways to trip it. Two events sharing the code can still have unrelated triggers.
On a Windows-based HMI the application in question is the runtime that draws your screens and polls the controllers. When the operating system kills it, the fatal-error box goes up and the screen stops updating. The code tells you the class of failure: an invalid memory access inside one application. The trigger sits outside the message, and only the context around the event supplies it.
Why does the message show the runtime name and an address?
The message names the executable that crashed and prints the address where the invalid access landed. The line Exception: 0xC0000005 followed by a hex address tells you which application died and where in memory, but nothing about which screen, object or cable caused it. The executable name is worth reading: it tells you the crash is inside the HMI runtime, not in the operating system or a background service.
The address records where the invalid access landed in that run. It is a breadcrumb for the vendor's engineers, and the same problem can print different addresses on different runs. Match recurrences on the code plus the screen and the action. Treat the address as something to photograph for the vendor, never as a part number.
Does 0xC0000005 mean the panel hardware is failing?
No. The same code appears in ordinary Windows software when an application touches an invalid address. A hardware decision needs a pattern, such as the code appearing in several different applications or returning immediately after every restart on a freshly loaded project. The code is not an HMI-specific fault. Engineering software hits it too, and one documented support case describes crashes with the same exception code across several different programs on one machine, which points the investigation at the shared environment: memory pressure, a driver, the operating system layer.
Replace hardware on a pattern, and only on a pattern: an immediate repeat after every restart on a clean project, or the same crash in applications other than the runtime. The discipline is the same one that applies to touch faults: check ghost touch at high temperature before replacing the panel. A single event that one restart clears, followed by weeks of normal running, is not proof of a healthy panel, and it is not proof of a failing one; it is an unexplained event with a record attached.
Should you restart the panel when this error appears?
Restart when production needs the panel back, and capture the context first whenever the panel still responds. The restart clears the runtime from memory and takes the active screen, the last touch and the communications state with it. Capture within 15 minutes of the fault, before shift change scatters the operators who saw it. The order is capture first, restart second. The list in the next section costs one photograph and a couple of written lines.
If the screen is frozen and the line needs the machine back, run the site's approved recovery procedure, restart, and log afterwards what the operator remembers about the screen and the last action. One safety note: if the panel is the only view of a running process, restart it under the machine's approved procedure, with the process state confirmed safe first.
A restart is a recovery, not a diagnosis. Before releasing the machine, confirm the controller side as well as the panel side; the mechanics are in what the PLC mode switch does to panel communications and a RUN restart.
What should you record before the restart wipes the state?
Record three things: the full on-screen message photographed with the code and address, the active screen and the last object touched, and the communications picture, meaning which controllers the panel was talking to and whether each link was live.
- Photograph the whole message box, including the runtime application name, Exception: 0xC0000005 and the address line, close enough that the codes stay readable later.
- Name the active screen and the last object touched. If the operator cannot recall, write unknown; a hole in the record is information too.
- Note the communications picture: which controllers were linked, what was being polled, and whether a tag, schedule or recipe edit landed shortly before the fault.
Read the panel model, runtime version and project revision from the panel's own information screens while they are still up. Capture exact wording on every message, because HMI failure messages look alike and mean different things. An error during a project download has its own documented causes, among them a missing panel image on the engineering PC, and it takes a different fix from a runtime crash.
What causes 0xC0000005 on an HMI panel?
Documented causes are specific, never generic. One HMI vendor's support note ties a fatal application error to incorrect tag addressing in a data-logging configuration. Another vendor's support entry describes a runtime shutdown that appeared only when the station was powered on. If your project writes trends, logs or recipes against one or more controllers, audit the tag map and the logging configuration first; pointing one HMI panel at multiple PLCs with per-device tags is the configuration style that keeps those maps straight.
A crash that clusters at power-on points at startup timing: the runtime coming up while links or hardware are not ready. Startup is cheap to test, and it belongs among the startup and runtime checks you run before choosing a panel.
So the documented paths give three first checks, each tied to a pattern: tag and data-log configuration when the project logs data, startup timing when the fault clusters at power-on, and the shared environment when the code escapes the runtime and takes down other applications with it.
What does the change-one-variable example look like?
In this example a packaging-line panel with 12 screens shows Fatal Application Error twice in one week. Both captured events sit on screen 7, the trend screen, so the first single test is that screen and nothing else. Both captures read Exception: 0xC0000005; the first printed Address: 03FA0E54, the second a different address. That fits what the code does: the address records where the invalid access landed in that run.
The arithmetic points one way. There were 12 screens on the panel, and 2 of 2 events sit on screen 7, with no other screen and no other operator action in either record. Two events landing on the same one of 12 screens by chance is the unlikely alternative. The shared screen is the signal.
The test: load a copy of the project, open screen 7, and repeat the operator sequence that preceded both events. One variable moves; communications stay as built, no tags are edited, and the panel hardware is untouched. If the runtime dies on screen 7 again, the trigger lives in that screen's objects or its logging configuration. The fix is an edit to screen 7 in the engineering tool, retested the same single-variable way. If screen 7 survives the full sequence, the screen is cleared and the next single change is communications: run the same sequence with the panel's controller links brought up one at a time, recording the result of each pass.
Decision: start at screen 7, and never change the screen and the communications setup in the same test. A double change that appears to fix the fault hides which change mattered, and the fault returns to bite the next shift.
When should you stop testing and call the vendor?
Stop and escalate when the error returns with no safe test path, when a test would interrupt a running machine, or when two clean restarts in a row are each followed by an immediate repeat. Send the vendor the photographed messages, the screen names and the project revision. The escalation package is the record already built: photographed messages with codes and addresses, screen names and operator actions, panel model, runtime version, project revision, and the list of single-variable tests with their results.
The same capture-and-compare discipline closes out sporadic access violations on controller rungings; troubleshooting sporadic PLC access violations follows the identical path of record, one restart, one change. Keep the record even after a clean recovery. If a second event lands months later, the first capture turns the repeat into a comparison instead of a fresh mystery.
Recommendation: Photograph the message box and log the active screen, the last touch and the communications state before any restart; restart once to recover production; if 0xC0000005 returns, change one variable per test, screen and action first, then communications, then startup timing; and escalate the captured record to the vendor when a repeat follows a clean restart.
Questions
Does a 0xC0000005 crash erase the project on the panel?
No. The exception terminates the running runtime application, and the project stays in panel storage. A restart reloads the same project, so there is nothing to rebuild after a clean recovery. Reload the project only as a deliberate single-variable test, and record the project revision before and after, because a silent reload destroys the evidence you are trying to compare.
Does the same exception code appear on panels that do not run Windows?
0xC0000005 belongs to Windows, so a runtime on any other operating system reports its own codes or plain error text instead. Do not map advice between platforms by the number: the equivalent failure on a non-Windows panel carries a different code, and the vendor's manual for that runtime is the place its meaning is documented.
What goes in the maintenance record after a one-time event?
Date, shift, panel identification, project revision, the photographed message with its code and address, the active screen and last operator action, the communications state at the fault, and one line stating that a restart recovered the panel. If the site keeps a shared log, tag the entry to the panel, not to a person, so any later event can be compared against it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.