Yokohama MID Server upgrades do not upgrade all jar files in lib, causing NoClassDefFoundError for various classes, and MID Server Down - Known Error

Yokohama MID Server upgrades do not upgrade all jar files in lib, causing NoClassDefFoundError for various classes, and MID Server Down Description After a MID Server is upgrade to Yokohama, it may not have fully upgraded all the files. Some Java class (.jar) files from the agent\lib folder (and possibly other fields) remain on the previous version.

On first startup after the upgrade, the MID Server's agent log will show an error like:

ERROR (WrapperStartStopAppMain) [Main:107] Error encountered during MID server execution java.lang.NoClassDefFoundError: com/snc/automation_common/integration/creds/IAuthGenerator

or with one of these other classes:

java.lang.NoClassDefFoundError: com/snc/midserver/init/api/InitializationTaskBinder java.lang.NoClassDefFoundError: com/snc/midserver/extension/api/IExtensionProbeHelper

and possibly more.

The MID server cannot be started, and remains Down. That may cause any features and integrations using that MID Server to have an outage if clustering is not used or no other failover mid servers are available.

Steps to Reproduce

Steps to reproduce this on demand are not known yet. It has been seen in upgrades to Yokohama, mainly from Xanadu.

The upgrade runs normally, up to the point that the upgrade process starts the MID Server Service again.

At this point the MID Server application errors on startup with a java class dependency error shown in the agent log:

2025-06-18T10:30:51.727+0100 ERROR (WrapperStartStopAppMain) [Main:107] Error encountered during MID server execution java.lang. NoClassDefFoundError : com/snc/automation_common/integration/creds/ IAuthGenerator at com.service_now.mid.creds.provider.AuthGeneratorModule.configure(AuthGeneratorModule.java:15) at com.google.inject.AbstractModule.configure(AbstractModule.java:64) at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:426) at com.google.inject.spi.Elements.getElements(Elements.java:113) at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:160) at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) at com.google.inject.Guice.createInjector(Guice.java:87) at com.google.inject.Guice.createInjector(Guice.java:69) at com.snc.llama.thirdparty.guice.boot.api.GuiceEntryRunnableFactory.create(GuiceEntryRunnableFactory.java:61) at com.snc.llama.bootstrap.api.Bootstrapper.run(Bootstrapper.java:48) at com.snc.llama.thirdparty.guice.boot.api.GuiceBootstrapper.run(GuiceBootstrapper.java:27) at com.service_now.mid.Main.doStaticStartRequest(Main.java:492) at com.service_now.mid.Main.doStaticCommandDispatch(Main.java:460) at com.service_now.mid.Main.main(Main.java:105) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.tanukisoftware.wrapper.WrapperStartStopApp.run(WrapperStartStopApp.java:429) at java.base/java.lang.Thread.run(Thread.java:840) Caused by: java.lang.ClassNotFoundException: com.snc.automation_common.integration.creds.IAuthGenerator at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525) ... 20 more We have also see the same error for different classes on first startup after an upgrade as well:

java.lang.NoClassDefFoundError: com/snc/midserver/init/api/ InitializationTaskBinder java.lang.NoClassDefFoundError: com/snc/midserver/extension/api/ IExtensionProbeHelper The wrapper.log/glide_dist_upgrade log doesn't give any indication that there was a problem copying/replacing/upgrading files. In fact it says it worked e.g.:

INFO | jvm 1 | 2025/05/18 02:28:11.453 | May 18, 2025 2:28:11 AM com.snc.dist.mid_upgrade.UpgradeMain migrateToTarget INFO | jvm 1 | 2025/05/18 02:28:11.453 | INFO: Finished copying files.

Using folder listings from after the upgrade, but before the installation was manually repaired by replacing files, new jar files were seen in lib, but old pre-upgrade files were still there in lib.

e.g. for a Xanadu Patch 8 to Yokohama Patch 4 upgrade, and using WinMerge to diff the 2 zip install files, it's clear that the 3/4/25 files are the Xanadu Patch 8 ones, and 4/6/25 are the Yokohama patch 4. Some jar files are added, some in the lib folder were not changed, but most were. That's what we expect to be there after the upgrade. https://install.service-now.com/glide/distribution/builds/package/app-signed/mid/2025/06/04/mid.yokohama-12-18-2024__patch4-05-14-2025_06-04-2025_1836.windows.x86-64.zip https://install.service-now.com/glide/distribution/builds/package/app-signed/mid/2025/04/03/mid.xanadu-07-02-2024__patch8-03-26-2025_04-03-2025_0833.windows.x86-64.zip

But looking at a folder listing of the installation after the upgrade. e.g. - mid-integration-hub.jar is there, added by Yokohama, with the correct file timestamp of the Yokohama version. The upgrade clearly did do something. - but mid.jar, was still the Xanadu version size/timestamp. It should have upgraded that, but didn't.

Workaround This problem has no workaround, is currently under review and targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available.

This corrupts MID Server installs. A manual repair is likely to be needed if this MID Server is to be retained, to replace/delete/add the missing/mismatched files. You may need help from tech support for that, so open a case, because as well as the need to confirm the root cause and collect evidence to help get this problem fixed, the specific mid server configuration will need taking into account, and extra steps need doing to get the MID Server working as it was.

That should always be considered a last resort, and a fresh clean install using the new instance version's installer will always be the best solution, as that would also resolve any existing configuration issues that may have contributed to the problem in the first place.