Setting the image path of CLR module in Windbg - module

When I run the 64-bit version of Windbg on a Win7 64-bit machine, it shows the image path of the the clr.dll module to be the 32-bit version of the framework, not the 64-bit.
Is there any way to specify the image path for the clr.dll module in Windbg? Should Windbg 64-bit running on a 64-bit box be grabbing clr.dll from the Framework64 directory?
0:000> lmvm clr
...
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
I have a 64bit w3wp.exe dump that I cannot use SOS on, and I believe it's because of incompatible frameworks, caused by this 32bit clr dll image.
0:000> .loadby sos clr
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos) failed, Win32 error 0n193
"%1 is not a valid Win32 application."
Once again, the dump is from a 64-bit server, I've doubled checked that it has the same CLR version as my Win7 64bit machine I'm debugging on, and I'm running 64bit Windbg.
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
...
Windows 7 Version 7600 MP (4 procs) Free x64
When I run 32-bit Windbg, it loads SOS fine, but then errors when I try to run !threads, with the ubiquitous Failed to load data access DLL, 0x80004005 error.
Can the CLR image be set and if so, how?

This actually sounds like an mscordacwks issue. Take a look at http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx for an excellent guide on resolving this.

Related

VCL App Deploying with runtime libraries....how to link to 32 bit vs 64 bit?

I have a Win 7 64bit system that I deploy VCL apps to.
I have both 64bit VCL and 32bit VCL applications running on that system.
The 64bit application has been built in C++ Builder 10.0 Seattle and runs fine.
The 32bit application is being upgraded to Seattle, and that's where the confusion comes in. I was getting an error on not able to find a wrapper in the borlndmm.dll. I updated the DLL in both the System32 and SySWOW64 directories from the C++Builder's Win32 and Win64 redist folders. I am now getting the error "application was unable to start correctly 0xc00007b". It looks like the 32bit application is linking to the 64bit DLL.
How can I have 64bit and 32bit VCL applications co-exist on the same system and link to their respecitve DLLs correctly? How do I correct this?
I wish I could compile the 32bit application to not require borlndmm.dll, but even with the "Link with Dynamic RTL" and "Link with runtime packages" options disabled, I get an error on linking with borlndmm.dll.

"interops made for a different target platorm." and "ActiveX not properly registered"

Thank you for any and all help... I've never seen this bug before... I have several vendor supplied DLLs for talking to a Signature Capture Device. We build our C# windows app platform target set to "any cpu" on an XP x86 machine. When the application is run on Win7 32-bit computer it works fine. When it is run on Win7 64bit computer it fails.
Running the Visual Studio 2010 debugger on Win 7 x64 in "Debug mode" works fine. Running in Release mode on Win7 x64 fails.
I can change the platform to target x64 then Release mode gives "interops made for a different target platorm." When I delete and recreate the interops for 64 bit target I get "ActiveX not properly registered".
Thank you in advance.
Make sure you module not depends of 32 bits libs.
Use Dependency Walker or Fuslogvw.exe to diagnose module load fail.
To interop 32/64 bits COM see Access x86 COM from x64 .NET
My solution was to change the Project->Properties->Build->Platform Target from "any cpu" to "x86". The application now runs on win7 64 bit and 32 bit and XP x86.

ODP.NET x64 ANYCPU and Prefer 32-bit setting

My machine has the latest Oracle ODP.NET x64 installed (xCopy version). My machine is x64. I don't know if the target machines will be x86 or x64 so I have set the build properties to AnyCPU in VS 2012. There is a default checkbox active "prefer 32-bit"
Compilation is OK but when I run the code it says it can't find the assembly. Unchecking "prefer 32-bit" solves this problem.
But what is causing this? I would assume that prefering 32-bits is okay but that it would use x64 if that's the only option.
Any ideas?
"Any CPU" with "Prefer 32-bit" will run as a 32-bit process on 64-bit machines. And because a 32-bit process can't load the 64-bit ODP.NET assemblies (and native DLLs too), it throws the exception you mentioned.
You can read more about the "Prefer 32-bit" setting here: https://stackoverflow.com/a/12066861/631802

How to build x64 with monodevelop?

I would like to build a x64 package of a project I wrote in monodevelop. I can change the project compiler options from x86 to x64, but if I do this, I get the error:
Error CS0016: Could not write to file `AudioCuesheetEditor', cause: AMD64 (CS0016) (AudioCuesheetEditor)
How can I build packages for x64 systems?
Thank you for help!
Use the any cpu configuration
You'll get x64 on a 64-bit operating system, x86 on a 32-bit operating system. Automagic provided by the just-in-time compiler.
BUT On windows x86 with anycpu there is no problem. Using windows x64 will crash becaus gtk-sharp has no x64 build. So on windows x64 you have to build x86.

Register 32 bit COM DLL to 64 bit Windows 7

I have a 32 bit COM component DLL and this DLL is written in Delphi.
It's a Win32 DLL.
I want to use this DLL in my Visual C# project on .NET platform.
I can't add reference to this DLL in the project.
I try to register it in Command Prompt as Administrator in Windows 7 64 bit, but I get this error:
Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe.
First I put DLL file to windows/system32 folder. Then I open Command Prompt as Administrator. I write regsvr32 huginalpha.dll and execute this command. But I get the error. what can I do?
The problem is likely you try to register a 32-bit library with 64-bit version of regsvr32. See this KB article - you need to run regsvr32 from windows\SysWOW64 for 32-bit libraries.
For 32 bit DLLS in Windows 64 bit platforms:
Copy whatever.dll to c:\windows\sysWOW64\
Open a CMD prompt AS ADMINISTRATOR (very important)
In the CMD window:
CD c:\windows\sysWOW64\
regsvr32 whatever.dll
You will then be executing the 32-bit regsvr (c:\windows\sysWOW64\regsvr.exe) on a 32 bit dll
I believe, things have changed now. On My Win 2008 R2 Box, I was able to register a 32 bit dll with a 64 bit regsvr32 as the 64 bit version can detect the target bitness and spawn a new 32 bit regsvr32 from %SYSWOW% folder.
Refer: Registering a 32 bit DLL with 64 bit regsvr32
http://onerkaya.blogspot.com/2013/03/register-com-dll-on-windows-64-bit.html
Retrieving the COM class factory for component with CLSID {...} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
if you try this;
c:\windows\system32\regsvr32.exe < filename >.dll
you can still take this exception. so IIS- pool Advanced settings, Enable 32 bit application : true ;)
To register a comm .dll or .ocx on Windows 7 32-bit, do the following:
Copy .dll or .ocx to c:\windows\system32
Type cmd in Run menu, it will search cmd.exe, right click and click Run as Administrator
It will show a prompt at c:\windows\system32
Type
regsvr32 ocxname.ocx to register .ocx
or
type regsvr32 dllname.dll to register .dll
put the dll in system32 or syswow32 directory, and use appropriate regsvr32 to register it.
wiered that even though it gave failed to register error, I rebooted my WIN 7 64 AND my vb app loaded the dll just fine!!
If problem not resolved, when using SysWoW64 version of regsvr32, make sure all library dependencies have same archetecture. For example, when
regsvr32 lib_x86.dll fails to register library, and
%SystemRoot%\SysWow64\regsvr32 lib_x86 also fails, try to load lib_x86 to Dependency Walker application to see whole list of dependencies. If any item have 64-bit archetecture, here is the reason, why regsvr32 fails to load 32-bit library.
Try to run it at Framework64.
Example:
32 bit
C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe D:\DemoIconOverlaySln\Demo\bin\Debug\HandleOverlayWarning\AsmOverlayIconWarning.dll /codebase
64 bit
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe D:\DemoIconOverlaySln\Demo\bin\Debug\HandleOverlayWarning\AsmOverlayIconWarning.dll /codebase
I was getting the error "The module may compatible with this version of windows" for both version of RegSvr32 (32 bit and 64 bit). I was trying to register a DLL that was built for XP (32 bit) in Server 2008 R2 (x64) and none of the Regsr32 resolutions worked for me. However, registering the assembly in the appropriate .Net worked perfect for me.
C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe
Below link saved the day
https://msdn.microsoft.com/en-us/library/ms229076(VS.80).aspx
use the relevant RegSvcs as specified in the above link
c:\Windows\Microsoft. NET\Framework\v4.0.30319\RegSvcs.exe ....\Shared\Your.dll /tlb:Your.tlb