HMI software crashes at startup after a DLL error: isolate the layers

What the fields in a startup crash report mean

A Windows startup crash report has five fields, and each one carries specific information:

• AppName names the executable that failed. In the case behind this article it was ea-pgm.exe, the HMI configuration program itself.
• AppVer gives that executable's version, 1.21.6.16.
• ModName names the module that was loaded when the fault fired, mfc42u.dll. That file is the MFC runtime library, a Windows component that many engineering applications load as they start. It ships with Windows, not with the HMI package.
• ModVer gives the module's version, 6.2.8071.0.
• Offset records the position inside that module where the faulting instruction sat, 000044a8. That is data for whoever holds the module's symbols; it is not a repair instruction.

Two conclusions follow. First, the named file is a Windows runtime component, so the report points at the Windows layer before it points at your project. The vendor's guidance for this exact fault was that something had corrupted, overwritten or deleted the runtime file. Second, write all five fields down before you touch the machine, together with the installed release and the date of the last successful start. Recording the five fields takes under 5 minutes, and every test that follows is measured against that baseline. A test that changes the ModVer or the offset has produced a result.

This article covers software that will not start at all. For a crash partway through editing a project, work through HMI editor crash diagnosis before software repair first.

Symptoms and what each one points to

• Crash right after the splash screen, report names a runtime DLL. The program loads its libraries and fails while starting. Work the layer tests below.
• The same fault after you try several copies of the named file. The file on disk is not the variable. Stop swapping DLLs and run the second-PC test.
• The same fault after you unregister the file. Windows still found and loaded a module, so the file exists and starts executing. The fault sits inside execution, where file replacement cannot reach.
• A limited edition of the same software starts normally. The limited build installs fewer shared components, so its clean start shows the PC runs the vendor's software. It does not prove the full package's dependencies are intact.
• The failure began after another program was installed or removed. That window holds the likely trigger, and its date is the restore point you will target.
• The same crash on a second PC with the same installer. The installation files or the release are the suspect. Get known-good installation files through the vendor's normal distribution and install clean.
• It starts on the second PC. Leave the install alone and repair the original PC's Windows environment.

Plan the window before you start

Each layer test is short enough to fit one maintenance window. Budget about 30 minutes for the second-PC test, about 20 minutes for a rollback to a restore point, and about 45 minutes for a repair or clean reinstall. These are planning figures for a single PC with its project files already copied off; the copies themselves usually take under 15 minutes on a USB drive or a network share. If the PC sits on the production network, do the changing tests outside production hours, because a rollback removes software installed after the point you target.

Test the installation on a second PC

This is the cheapest test that splits an install problem from a PC problem, and it changes nothing on the original machine.

1. Take the same installation media and release that produced the fault.
2. Install the full software on a second PC that meets the vendor's stated requirements.
3. Start it and let it run past the splash screen.
4. Write down the result: started, the same fault, or a different fault.

If it starts, the installation is good and the original PC's Windows layer holds the problem. Move to the restore point. If the same crash appears, get fresh installation files through the vendor's normal distribution before you change either machine, and run one clean install from the new media. If no second PC is available, go straight to the restore point and treat this test as the one you owe the process later.

Roll back to a restore point from before the change

In the case behind this article, the software had started cleanly two months earlier, and the only change in that window was one office application being replaced by a newer version. That date is the target.

Before you roll anything back, copy every project file off the PC to a USB drive or a network share. If one of them will not open, recover it first; the steps are in recover a project that crashes on open. Note any other software or settings changed after your target date, because the rollback undoes those too.

Windows lists its restore points in the recovery options for your version; the recovery documentation for the version you have confirmed shows the exact path to them. Pick the point dated before the fault and restore to it. Then start the HMI software.

If it starts, reinstall the program the rollback removed and watch for the fault to return. If it returns, you have found the trigger, and you can take it up with that program's vendor. If startup still fails, the restore has narrowed the field. Move to the Windows repair.

Repair the Windows version you confirmed

Confirm the operating system and its service pack in system information before you pick a repair. The documented suggestion for this exact fault, on a machine running Windows XP, was to reload Service Pack 2. Do not carry that onto any other Windows version, and do not put an old service pack on a current system.

On the version you have confirmed, use the repair options in the same recovery documentation you used for the restore point. A repair replaces damaged Windows components and leaves your files and installed programs in place. Treat it like any controls maintenance job: project files already copied off, a known way back, and the work done in a maintenance window if the PC sits on the production network.

Reinstall clean, and reformat last

If the fault survives the restore point and the repair, remove the HMI software completely with its own uninstaller, restart, and reinstall from known-good media. Do the removal and the install through the installer. Hand-copied DLL files dropped into Windows or program folders are how version mismatches start, and they gave this fault its name.

Record the release number with every attempt. In the case behind this article, updating to the latest release did not clear the fault, and the crash returned after a revert to the original CD install, so updating the release alone did not fix it. Your record turns results like that into data for the vendor.

Reformatting is the last step, and it is safe only once three things are true: project files are copied off and verified to open, installation media for everything the PC runs is in hand, and you have a plan for putting the machine back into service. While the machine is down, a separate shop-floor notice board can keep shift targets and status visible without depending on the HMI PC.

Example: one report worked through to a decision

The report, exactly as it was recorded:

History: the software finished a project two months earlier; since then, one office application was replaced with a newer version. Today the program stops after the splash screen on every attempt.

Reading the numbers. Several other copies of module version 6.2.8071.0 produced an identical fault, so the file on disk is not the variable. Unregistering the file and restarting produced the same report instead of a missing-file error, so Windows finds and loads a module every time and the fault happens while it runs. The offset 000044a8 repeated across every attempt, so the fault is stable, and any test that changes it has done something.

Second PC test with the same installer. If the software starts there, the install and the media are good, and the decision moves to the original PC: restore to the point dated just before the office-application change, and if startup still fails after that, run the repair for the confirmed Windows version. If the same crash appears on the second PC, the decision moves to the installation files: fresh media through the vendor's normal distribution, then a clean reinstall.

For this case the whole sequence fits a 60-minute maintenance window: 30 minutes for the second-PC test and 20 minutes for the rollback, with 10 minutes to spare for recording results.

Decision for this report: stop replacing mfc42u.dll, run the second-PC test first, and hold the five recorded fields as the baseline every later test is measured against.

Recommendation

Recommendation: Treat a startup crash that names a runtime DLL as a Windows-layer fault first. Record all five fields of the report, then test in this order: the same installer on a second PC, a restore point dated before the last software change on the original machine, the repair path for the Windows version confirmed in system information, and a clean reinstall through the HMI software's own installer. Replace a DLL by hand only when the vendor's documented procedure for your release says to, and copy project files off the PC before every test that changes the system.

Questions