We packaged an application that was giving out an error message at a certain point in the program:
Fortunately, this was a nice repeatable error.
What happens is the program generates this message when it’s importing a word doc into its database. This error message doesn’t stop the program from importing or causes a failure, and the process actually completes successfully. Even stranger is after this message appears and you click OK it will not pop up again and you can repeat the process ad infinitum without this prompt… Until you quit and relaunch the program. Then it will prompt the first time but then never after.
But having this prompt even once is unacceptable to our users. So how can we solve it? Let’s examine the clues we’ve been given. “An application has made an attempt to load the C runtime library incorrectly”. So it’s crashing when loading a Visual C++ Runtime Library. Which file? Unfortunately, the path got truncated. But Procmon will tell us! I opened procmon, set it only look for ‘Load Image’ operations and then traced the process name. This is where it crashed:
It crashed loading the MSVCR80.dll. What’s curious is this DLL and the version and everything exist natively in the system. I’m unsure why it was captured but the program is deferring to the AppV msvcr80.dll as opposed to the natively installed one.
Using Process Explorer I searched for this DLL and confirmed that it’s loaded in multiple places, with all programs except the AppV program using the natively installed one.
What I suspect is happening is that there is some form of DLL sharing occurring and Windows is telling the program that “your loading this file?! I already have it loaded and used by all these other programs. Use that instead you dummy!”
So can we force the program to use the natively installed DLL’s?
This program automatically installs some Visual C++ runtime libraries and these are captured by AppV automatically. There is no way to remove them as they are not a separate installer or anything we can just hack out during an install.
However, we can just manually delete them. If they don’t exist in the package AppV should automatically look for those files in the native file system.
I then went into the AppV Sequencer and ‘Edit’ on the package, selected ‘Package Files’ and deleted the ‘winsxs’ folder:
Did it work?
This is what procmon showed me for the new package without these folders:
The msvcm80.dll is now using the natively installed version and path! And I did not get the error message any more and the operation worked successfully! Another success story.