I have a .NET 3.5 application that is compiled with a configuration with Any CPU. The application is referencing an OCX file with an interop assembly.
When the application is installed on a Windows 7 32-bit everything works fine. When the same appplication is installed on a Windows 7 64-bit, we get an error:
Retrieving the COM class factory for component with CLSID {CCB90182-B81E-11D2-AB74-0040054C3719} failed due to the following error: 80040154
Using Process Monitor from SysInternals I could see that on the 32-bit OS the system is trying to load the following registry key.
HKCR\Wow6432node\CLSID\{above CLSID}\InprocServer or
HKCR\Wow6432node\CLSID\{above CLSID}\InprocServer32
which are available and that's why the application works.
On the 64-bit version Windows is looking for
HKCR\Wow6432node\CLSID\{above CLSID}\InprocHandler or
HKCR\Wow6432node\CLSID\{above CLSID}\InprocHandler32
None of them exist.
How can it be made to work on Windows 7 64-bit?
Since it's an InprocServer it runs in calling process context. If the calling process is AnyCPU running on x64 platform it can run only x64 COM components.
So you either need to get x64 version of component or compile your application for x86 platform.
If this COM component would be an Local or Remote server that would work as well...
Sometimes can help the next actions:
create an filexx.bat with
#echo un-register
regsvr32.exe completePathOfOcxOrDllFile -u
#echo register
regsvr32.exe completePathOfOcxOrDllFile -u
#pause
#exit
And, of course, run the bat file as admin (right click file and click in run as admin).
Related
I'm trying to install MCR on a virtual machine, Windows server 2012 (that doesn't have MATLAB).
I manage to send the file over and run the installation program.
It installs with no problem.
But then I still get:
Could not find version 8.1 of the MCR
Anyone has an idea?
I tried to do it as administrator as well, but doesn't matter.
Can I change some path or something manually?
The error message is also:
attempting to load mclmcrrt8_1.dll
On the machine you used to build the standalone, get the correct MCR version with the following command:
>> mcr
The WIN64 MCR Installer, version 8.2, is:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\win64\MCRInstaller.exe
MCR installers for other platforms are located in:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\<ARCH>
<ARCH> is the value of COMPUTER('arch') on the target machine.
Full list of available MCR installers:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\win64\MCRInstaller.exe
For more information, read your local MCR Installer help.
Or see the online documentation at MathWorks' web site. (Page may load slowly.)
Take the file it names and install it on the server. You must match the architecture too.
Here are links to the installers.
I have received a mini dump file from our network support team. They complain that one of our sites on the production node causes high cpu usage.
The Windows server is x64 but the IIS App Pool is running in 32-bit mode. The network/support guys have used the default task manager to create the dump file so I assume the dump file must be a 64-bit one.
I downloaded WinDbg x64. Then I tried to follow the instruction given in the link below to find which part of the code can be problematic:
site
Although the dump file and WinDbg both are 64-bit, when I run "lmvm clr"command, the debugger shows this line:
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
If I run this command:
.loadby sos clr
and then !pe command, I get "no export !pe found" (this happens with any other command such as !CLRStack).
If I get the 64-bit version of mscordacwks.dll and sos.dll, and copy them into the symbol folder, the libraries will be loaded but upon running !pe command I will get "Failed to load data access DLL, 0x80004005 error message!
What I am doing wrong? I asked the network team to send me the .dll files (sos.dll and mscordacwks.dll), I copied them to the symbols folder but nothing changed.
p.s. I have read all the similar posts but none helped.
Open the dump in a 32-bit debugger and run !wow64exts.sw. You should now be able to load SOS and run commands, though not all commands will work. This will help, but still the best solution is to gather the dump with a 32-bit tool.
When changing a project from targeting .NET 4 to .NET 4.5 I get the following added to the project file for each build configuration:
<Prefer32Bit>false</Prefer32Bit>
What does this mean? The only documentation I could find on MSDN wasn't too clear.
Sets the 32BITPREFERRED flag. The app runs as a 32-bit process even on
64-bit platforms. Set this flag only on EXE files. If the flag is set
on a DLL, the DLL fails to load in 64-bit processes, and a
BadImageFormatException exception is thrown. An EXE file with this
flag can be loaded into a 64-bit process. New in the .NET Framework
4.5.
From the Corflags documentation
http://msdn.microsoft.com/en-us/library/ms164699.aspx
I downloaded the 64-bit Windows SQLite setup executable to install on my Windows 7 x64 machine:
sqlite-netFx40-setup-bundle-x64-2010-1.0.78.0.exe
(11.60 MiB)
and ran the setup. It failed with this error:
Could not open
HKEY_LOCAL_MACHINE\Software\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
There was no "AssemblyFoldersEx" key beneath "v4.0.30319". So I created the key there and re-ran the setup, which completed this time without error.
However, when I try to add the reference, System.Data.SQLite does not appear in the list of components on the .NET tab.
What would be the next troubleshooting step? Thanks
Since VS2010 is Win32 and not x64, you need to install the Win32 setup to get design-time support. You can still use the x64 binaries with your application, the Win32 is only needed for VS integration.
Yes, you need to install Win32 SQLite for design time support; after download and executed 32bit setup (sqlite-netFx40-setup-bundle-x86-x-x.x.x.x.exe), if you still facing the same error you can run the VS designer components 32bit installer without the option checked by following steps:
Open a Visual Studio command prompt.
Change to the "System.Data.SQLite\2010\bin" install directory.
eg: CD D:\Programs\System.Data.SQLite\2010\x86\bin\
Run the following commands:
corflags /32BIT+ /Force Installer.exe
sn -k System.Data.SQLite.snk
sn -Ra Installer.exe System.Data.SQLite.snk
Installer.exe -install true -installFlags AllExceptGAC -tracePriority Lowest -verbose true -noCompact true -noNetFx20 true -noVs2008 true -whatIf false -confirm true
Command explaination:
corflags /32BIT+ /Force Installer.exe
Using the "corflags" tool (part of the .NET SDK), flag the "Installer.exe" tool as 32-bit only
sn -k System.Data.SQLite.snk
Generate any strong name key pair (Any key pair SNK file will work here)
sn -Ra Installer.exe System.Data.SQLite.snk
Re-sign the "Installer.exe" assembly using the above generated strong name key pair
Installer.exe -install true -installFlags All... -confirm true
Run installer with neccessary flags, but the most important is to put in '-confirm true'; as this is the needed flag for SQLite installer which prevent user execute setup by clicking the installer.exe directly in windows explorer.
I'm trying to deploy an application on Windows Server 2008 (SP2 x64) and Windows 7 (x64), using VS2005 Installer Project. The MSI version (I think) it the 2.0.
Everything works fine, except that some registry keys and some files are not copied on the install machine. The MSI system doesn't notify about nothing (and I don't know whether MSI logs its operations).
Are there incompatibilities between my MSI installer project and these new OSes? It seems to me that the OS protect itself for being modified in some part.
For example, I'm trying to set the registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\WinLogon\SpecialAccounts\UserList\User
but it is not created. In the same installer there are many other keys, which are created like expected (as they always did before on Windows XP and Windows Server 2003).
To provide another example, I'm trying to install the file
%SystemFolder%\oobe\info\backgrounds\backgroundDefault.jpg
(where %SystemFolder% is typically "C:\Windows\System32"), but the file is not copied at all!!!
What's going on?
I've found the backgroundDefault.jpg file is located in another directory: %SystemRoot%\SysWOW64\oobe\info.
But I've not specified nothing about a System (64 bit) folder. How can I copy the file in the right place?
First, regarding logging, you can request MSI to create a log file of its operations like this:
msiexec.exe -i my_msi_file.msi -l*vx logfile.txt
This will create a log file called logfile.txt.
Second, it sounds like you're creating a 32-bit MSI and running it in 64-bit Windows. There is nothing wrong with this, but be aware that Windows is using file system redirection. Windows has a separate SystemFolder and HKLM/SOFTWARE keys to host 32-bit applications. If you look in the Registry at HKLM/SOFTWARE you'll probably see a sub-key called Wow6432Node -- this is where 32-bit apps write their Registry data.