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.
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)
Please log in to answer
Posted by:
MSIPackager
16 years ago
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.
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
16 years ago
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.
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
16 years ago
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
16 years ago
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.
"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
16 years ago
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.
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
16 years ago
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
Regards,
P
Posted by:
ogeccut
16 years ago
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.
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.