This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- R6034
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 29, 2009
01:02 PM
R6034
Out of nowhere our installation started throwing up a message box complaining of an R6034 error.
Now, the build machine was apparently updated recently to include the new version of the MSVCRT(4053)
It's actually throwing this error in a custom action that calls a .NET dll. Oddly enough the same dll is called(Different function) earlier in the installation during the interview phase(The error is thrown during the install phase, but after InstallFinalize)
The callstack looks something like this:
Has anyone seen anything like this? Does anyone have any suggestions? I have no idea what's going on. 😕
I've updated to a new MSM that includes the 4053 version of the CRT, and the policy files. I even tried installing it ahead of time on the machine(Before the install)
Runtime Error!
Program: c:\WINDOWS\system32\MsiExec.exe
R6034
An application has made an attempt to load the C runtime library incorrectly. Please contact the applications support team for more information
Now, the build machine was apparently updated recently to include the new version of the MSVCRT(4053)
It's actually throwing this error in a custom action that calls a .NET dll. Oddly enough the same dll is called(Different function) earlier in the installation during the interview phase(The error is thrown during the install phase, but after InstallFinalize)
The callstack looks something like this:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for '' threw an exception. ---> .ModuleLoadException: The C++ module failed to load during appdomain initialization.
---> System.DllNotFoundException: Unable to load DLL 'MSVCR80.dll': A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)
at _encode_pointer(Void* )
at _initatexit_app_domain()
at.LanguageSupport.InitializePerAppDomain(LanguageSupport* )
at.LanguageSupport._Initialize(LanguageSupport* )
at.LanguageSupport.Initialize(LanguageSupport* )
--- End of inner exception stack trace ---
at.ThrowModuleLoadException(String errorMessage, Exception innerException)
at.ThrowModuleLoadException(String , Exception )
at.LanguageSupport.Initialize(LanguageSupport* )
at .cctor()
--- End of inner exception stack trace ---
at ORD.DataItems.Shop.CreateDefaultProperties()
at ORD.DataItems.Shop..ctor(String extClass)
Has anyone seen anything like this? Does anyone have any suggestions? I have no idea what's going on. 😕
I've updated to a new MSM that includes the 4053 version of the CRT, and the policy files. I even tried installing it ahead of time on the machine(Before the install)
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 30, 2009
05:28 PM
For anyone interested...
ProcMon revealed that the error was happening because MsiExec was trying to load MSVCR80.dll from the path instead of the WinSxS directory. It eventually would find an older version in the path due to SQL Server being installed.
We still had the exception though. Oddly enough, taking an app domain out of the DotNetCoCreateObject call seemed to fix everything up.
I'm still not completely sure what caused the problem, but it seems to be better now.
ProcMon revealed that the error was happening because MsiExec was trying to load MSVCR80.dll from the path instead of the WinSxS directory. It eventually would find an older version in the path due to SQL Server being installed.
We still had the exception though. Oddly enough, taking an app domain out of the DotNetCoCreateObject call seemed to fix everything up.
I'm still not completely sure what caused the problem, but it seems to be better now.