Replacing CEAPI.DAT is completely fine, as long as the computers that were failing to have their spyware defs (CEAPI.DAT) update don't have spyware on them. Just delete/rename the corrupted ceapi.dat files and it'll get replaced.
I don't believe it's the ErrorDoctor definition causing the problem because that def is so old that it's disabled @ our site. (However, I recall seeing it triggered as part of the Win32.Trojan.Agent definition somehow? Sorry, I can't find where I saw that)
In our case, it's been the Win32.Trojan.Agent causing the issue every time. It seems to catch a lot of generic spyware variants, which is great,
but there seems to be an internal adaware script (not in LD definition) that tries to fix some registry entries as can be seen in the vulscan.log file - and of note it's currently deleting the kbdclass entry among others.
You can still use landesk to remote control the affected computer. If you want to play it safe, just disable the Win32.Trojan.Agent definition temporarily.
If it happens to anyone, it's fairly easy fix. It's easiest to just export good registry entries from another of the same model (HKLM\SYSTEM\CurrentControlSet, ControlSet001, ControlSet002) and import them to the affected computer and reboot.
Log files of note are vulscanX.log, softmonX.log file and c:\aaw7boot.log. bear in mind these log files can get overwritten, especially if the user doesn't reboot soon after vulscan and notice the issue.
If you don't have another model, check the device manager for unknown devices (Keyboard > Standard PS/2 Keyboard - is the device referenced in kbdclass registry). Check the detail tab - device instance path for the values needed in the registry.
I've been working w/ LD support (case 829299). I've supplied a bunch of logs and they're currently reviewing the issue.