Fix a class not registered error that closes an HMI editor

Why does the HMI editor report Error GUI-121: Class not registered?

Error GUI-121 is a Windows component activation failure, not an editor fault. The editor asked Windows for a registered software class and Windows answered with 0x80040154, class not registered, because the two files the editor names were missing or unregistered.

The message text "Class not registered" is the COM activation failure Windows prints elsewhere as 0x80040154. A program asks for a software class by its registration entry, and Windows cannot resolve that entry to a loadable component. The editor vendor's published diagnosis for this startup pattern names the pair outright: msadox.dll and msado15.dll. Each of the two must exist on disk and have its class entries written into the Windows registry. A gap in either one produces the same message. The project file never entered the picture, so the first decision is made here: repair the PC's components and leave the project alone.

Why did reinstalling the editor leave the error unchanged?

Reinstalling changes nothing because the two files belong to Windows, not to the editor. msadox.dll and msado15.dll ship with Windows XP and Windows 2000, so an editor install neither replaces nor registers them.

The install already run is the documented first attempt, and it left both symptoms as they were. A second runs another 30 to 45 minutes and buys the same result. Record versions before anything else: the editor release (1.1.1.3a in the documented pattern) and the Windows version with its service pack, written down the way you would check an HMI firmware revision before a project transfer, because the repair and any later support call both turn on those numbers. The repair order is not unique to one editor either: documented OPC errors that cleared after reinstalling core components in other automation software behaved the same way, with application reinstalls changing nothing.

Decision: one failed reinstall is enough evidence, and the second install belongs after the component repair, if the vendor ever asks for it.

What do the symptoms tell you about the cause?

The three symptoms together point at one cause: a startup error the editor survives, a closure triggered by object insertion, and no change after a reinstall, which is the signature of a missing or unregistered Windows component rather than a damaged project.

Tick the observations off one by one:

• Error GUI-121 at startup. A class the editor requests on launch cannot be resolved, and the diagnosis names the file pair to check.
• The editor opens after OK. The shell and the drawing tools run, so the fault sits in a component path, not across the whole install.
• The closure lands when you drag any item, a pushbutton for instance, onto the layout area. Insertion is the first action in the session that requests the missing class, and the exit there is the confirmation.
• A reinstall changed nothing. The component belongs to Windows, which points the next step at the file system and the registry, not at the editor media.

Do not dismiss the dialog and keep editing a production layout. The closure can land mid-drag, and edits made after the last save go with it. Test on a backup copy until the drag holds. Note where the fault lives too: in the editing PC's Windows components, so neither the machine's HMI panel nor any shop-floor screens mounted nearby is involved, and no hardware needs replacing.

How do you check msadox.dll and msado15.dll?

Check two things for each of the two files: that it exists on disk in the Windows ADO folder and that its registration succeeds. Record the result for both files before you repair anything. The checks take about 5 minutes.

Work through three steps and end with four recorded facts, two paths and two presence results:

1. Log in with administrator rights and open a Command Prompt, because the registration step later needs the elevated prompt anyway.
2. Look in C:\Program Files\Common Files\System\ado, where a stock Windows XP install keeps the ADO files, and note the exact path of each file you find. Both msado15.dll and msadox.dll should be present.
3. Treat presence as half the check. A file that exists but was never registered raises the same startup message as a missing file, so the registration commands in the next section produce the deciding result for each file.

With the four facts written down, the decision splits cleanly: both files present, go straight to the two registration commands; either file missing, repair the Windows data-access components first.

How do you re-register the two ADO files?

Register each file from an administrator Command Prompt with regsvr32, one command per file. Read a confirmation dialog for both commands as the pass. If a command reports the module could not be found, the file is missing and needs the component package. Each command returns in a few seconds.

regsvr32 "C:\Program Files\Common Files\System\ado\msado15.dll"
regsvr32 "C:\Program Files\Common Files\System\ado\msadox.dll"

Run the two commands one at a time. Registration writes class entries into the Windows registry, which a standard user prompt cannot do, so the elevated prompt is part of the requirement. A success comes back as a confirmation dialog naming the file. A report that the module could not be found means the file is absent, and the repair is the Windows data-access component package, not another editor install: for this Windows era the documented package is Microsoft Data Access Components 2.8, installed from the OS vendor's own distribution or from the recovery media that came with the PC, after which both commands run again.

Take the files from those two sources only. A msadox.dll with a matching filename from a download site is an unverified binary on a PC that edits production projects, and a mismatched build stacks a second fault on the first.

Recommendation: At the first GUI-121 startup error with a closure on object insertion, skip the second reinstall. Check msadox.dll and msado15.dll in the Windows ADO folder under Common Files, re-register both from an administrator prompt, install the Windows data-access component package first when either file is missing, and run the three pass tests on a backup project before production work returns to the PC.

Worked example: how does the fix run on a Windows XP bench PC?

The documented pattern is editor release 1.1.1.3a on Windows XP reporting Error GUI-121 at startup and closing on the first drag. The fix runs as two file checks, one component repair, two registration commands and three pass tests, in about 20 minutes end to end.

Say the bench PC in front of you is that machine, and the file check finds msado15.dll in C:\Program Files\Common Files\System\ado and msadox.dll nowhere on the PC. One missing file sets the repair order: install the data-access component package from the PC's own recovery media, a step that runs in about 10 minutes, confirm msadox.dll now sits beside msado15.dll in the ADO folder, run the two registration commands, and read two confirmation dialogs. The tally closes at 1 missing file, 1 component repair, 2 registrations, 3 pass tests.

The three tests run on a backup project and take about 5 minutes: startup with no dialog, a pushbutton dragged onto the layout with the editor staying open, then save, close, reopen and a second insertion. All three pass, so the production project is opened, its layout checked and saved, and the PC goes back on the bench. Had both files been present at the first check, the component repair drops out and the sequence is 2 registrations and 3 tests.

How do you verify the editor before production work goes back on the PC?

Verification passes when the action that closed the editor before, dragging an object onto a layout, now runs clean on a backed-up project through save, close, reopen and a second insertion. Startup with no dialog only opens the sequence.

Startup clears first and insertion decides: the drag is the action that closed the editor before, so a quiet startup is only the opening move. After three passes, open the production project, confirm the layout renders and saves, and return the workstation to service.

What do you send the editor vendor if the closure returns?

If the closure returns with both files present and both registrations succeeded, stop repairing and send the vendor six facts: the exact error text, the editor version, the Windows version and service pack, both file paths, both registration results, and the steps that reproduce the closure.

Use the vendor's own support channel, keep editing on the backup copy while you wait, and lay the findings out the way the HMI editor crash diagnosis before software repair page sets out: symptom first, versions second, environment third, repro steps last. The vendor then reads a record instead of a story. With two registrations succeeded and the three tests failed, the fault has moved past this page, and the environment record is the deliverable.

Questions