Failed with rc=41 (ya, I saw the blurb on the description tab)
add/remove programs shows 11.0.4 but publisher is IBM (that’s hilarious)
services console shows 11.0.3 in the name of the service
Upgrade to the latest version of BigFix Inventory (11.0.4) is now not relevant on BFI app box
Soon to open case.
Suggest before you start, reboot your app server.
They don’t check for rc=41 until the end and by that time, the damage is already done.
Hint to developers, check for rc=41 scenario at the beginning of action script and terminate immediately if the condition is there.
If the upgrade task fails when run from Console, the subsequent tries will not work. Try the following:
Download the Installer locally to the BFI server and extract it
Set the BFI Service to Manual mode
Launch the installer and go through the steps to see if it fails with the fail to copy message
If it’s successful then set the service back to automatic
Reran with relevancies removed and got a rc=50, most likely due to the already in existance 11.0.4 in add/remove. Windows service still has 11.0.3 in the name.
I was able to edit the registry for the name of the service to 11.0.4 and the nightly import seemed to go ok and UI has all indicators that version was updated.
The $64,000 question remains is what didn’t run as a result of the rc=41?
11.0.4 was the worse upgrade we have ever implemented. All scheduled reports no longer work unless the report author is logged into BFI, and we are not logged in that early in the morning. We must log in and generate the reports manually and distribute them manually every day.
HCL still does not have a fix.
We (SAM) perform testing after every upgrade but we focus on the records in the manual reports. I’ve worked with BFI about 10 years and have never seen anything like this. My biggest complaint is the time to repair. This is pulling our folks from the usual work to generate and distribute reports. Some of these reports take 20 minutes to generate/download just one so it really adds up when doing multiple reports every day.
Upgrade to 11.0.4 completed successfully and UI was accessible.
After 5 days, the BigFix Inventory UI failed to load.
Restarting BFI service did not resolve the issue.
I observed the following startup error in the bfiserver-stderr.log file on my system:
2025-09-04 17:23:40 Apache Commons Daemon procrun stderr initialized. JVMJ9VM013W Initialization error in function VMInitStages(7): cannot initialize modules path
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Workaround
We verified whether the modules file exists and is functioning correctly in the following path: <BFI installation directory>\jre\jre\lib\modules
It was observed that the modules file was missing.
As a workaround, we advised the customer to copy the modules file from the lib folder available in the following package:
<< See the KB article above for the link to the package that contains the necessary modules file >>
After placing the modules file in the mentioned directory and restarting BFI services, the issue was resolved.
After replacing the modules file, my BFI server started up correctly.
This sounds exactly what happened to me. The modules file disappeared about the same time as we did OS patching. It hard too believe the patching deleted the modules file, but it was there the Friday before patching and then gone after. A restore from backups of the file resolved everything.
I’m making a copy of the modules file at my other customers where they’re running 11.0.4, as a precaution. I cannot identify any patching scenario where that one file would be deleted, but that is also about when the file disappeared in my case as well.
