/build/static/layout/Breadcrumb_cap_w.png

MSVBVM60.dll

I need to make some changes to an older application. After install and on the first launch of the exe i get a critical error, and application wont launch, however every launch after that does not generate an error. Event viewer points to a MSVBVM60.dll which is a part of my package as a merge modual, and the version trying to install is older then a dll on the system. I tried using isolated component, tried downloading a new merge modual "is has same older dll"
And tried deleting a merge modual from an msi all together. after deleting it, its failing to install.
This is an error message that i am getting:
AppName: workman.exe AppVer: 5.3078.0.32 ModName: msvbvm60.dll
ModVer: 6.0.89.64 Offset: 0002951b
And this is from event viewer:
Faulting application workman.exe, version 5.3078.0.32, faulting module msvbvm60.dll, version 6.0.97.82, fault address 0x00078655.

Thanks for any help.

0 Comments   [ + ] Show comments

Answers (7)

Posted by: MSIPackager 12 years ago
3rd Degree Black Belt
0
MSVBVM60.DLL is a system file and comes under Windows File Protection which is why you can't downgrade it...

If your app will only work with the older version of the DLL then your only option is to try and isolate it but if it's registered (and I'm sure MSVBVM60.DLL is) then I'm not sure how you achieve this. Sounds like you've already been trying component isolation - guess you could explore .NET isolation. More info here:

http://www.myitforum.com/articles/6/view.asp?id=5181
http://www.myitforum.com/articles/6/view.asp?id=5206

I've had a similar problem in the past but never had any luck isolating a different version of a registered DLL... I did come up with a solution to the particular problem I had but it was far from elegant.

Your in the right place to find out though - hopefully one of these bright sparks will have the answer for you - then I'll benifit too [;)]

Regards,
Rob.
Posted by: instedit 12 years ago
Orange Belt
0
Have you tried isolating it to the exe's folder, and adding an empty "<exe_name>.exe.local" file to
the same folder.

This will make the NT Loader use any dll's from the exe's folder in preference to the
normal search path, including COM LocalServer32 specifications.

You can test this by installing your existing msi, and then putting the msvbvm60 and .local files
into the exe's folder. If it works, then set up your msi to do the same.
Posted by: MSIPackager 12 years ago
3rd Degree Black Belt
0
This will make the NT Loader use any dll's from the exe's folder in preference to the
normal search path, including COM LocalServer32 specifications.


So, even though the COM registry info under HKCR references C:\WINDOWS\system32\msvbvm60.dll you are saying that the .local isolation method will suffice?

I don't get how this works and previously when I'd used this method I didn't have any joy...

ogeccut - let us know how you get on!

Cheers,
Rob.
Posted by: instedit 12 years ago
Orange Belt
0
That's my understanding. From: http://msdn.microsoft.com/en-us/library/ms811700.aspx#sidebyside_topic8

"Once DLL/COM redirection is activated, whenever the application loads a DLL or an OCX, Windows looks first for the DLL or OCX in the directory where the application's .exe file is installed."

I believe this is regardless of whether a COM dll has registered a CLSID\InprocServer32 with the full path or not. But I could be wrong.

I am not suggesting this will work, as the VBRuntime is more complicated than just MSVBVM60.dll. The OP may have to isolate more than just this file.

And the article cited above does say "Do not attempt to isolate any of the files protected by System File Protection that ship with Windows 2000, including most .sys, .dll, .exe, and .ocx files."

But... when you have nothing left to try.

Incidentally, if anyone should implement this, make sure you read and understand the last paragraph of that article. It's very important.
Posted by: instedit 12 years ago
Orange Belt
0
Looks like I was wrong:

Note In Visual Basic there is currently no easy way for developers to write inherently side-by-side ActiveX controls. This is because the registration of Visual Basic-authored ActiveX controls writes the fully qualified path to the OCX file into the registry when the control is registered.

So having a full path in the InProcServer32 scuppers the .local thing. Which is good, because that means that LoadLibrary will respect the full path. You would hate to specify the full path in the call and have it ignored.

You may be able to wrangle a solution with Registration Free COM: http://msdn.microsoft.com/en-us/library/ms973913.aspx

But I don't envy you writing the manifest that captures all the COM registrations for the VBRuntime.
Posted by: Inabus 12 years ago
Second Degree Green Belt
0
manifest isolation will do what you need as you put all the COM information in the .manifest file and a copy of the dll is put into the application folder.

Regards,
P
Posted by: ogeccut 12 years ago
Black Belt
0
The dll is not downgraded during the install. There are no rights no downgrade system dll's. But application launches after the first initial failure. So i assume it works with a current system dll.
IS component isolation diffrent from manifest isolation???

Thanks for any help.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ