I am working on Windows client application using c#, have two projects in my VS 2010 solution, the start-up project and a class library which uses third party COM interop DLL.My desktop is 64 bit and all the client machines are 64 bit as well.
If I keep the start-up project as any cpu in (build settings) and x86 for the second project which invokes the COM DLL, I am getting the following error:
Could not load file or assembly ... or one of its dependencies. An attempt was made load a program with an incorrect format.
If I keep both the projects as Any cpu, I am getting the following error:
Retrieving the COM class factory for component with CLSID .. failed due to the following error:
Any idea how to resolve the issue without converting the solution (all projects) to x86.
Well, I suggest you to look at DLL surrogates. This trick will definitely solve your problem, but only as long as you may change the registration info of the DLL inrpoc server in the registry.
If the class is configured to use a surrogate, it will run in a separate process. COM allows one to use an out-of-proc 32bit COM server from a 64bit application.
All you need to change is shown below:
Look at the following entry in the registry:
HKCR\CLSID\{CLSID_CoClass}
And look if it has the AppID field. If it does, just visit this registry key:
HKLM\Software\Classes\AppID\{APPID}
and add the DllSurrogate string key with no value.
If the class doesn't have an assosiated AppID, you may create it yourself. Then you may use your 32 -bit inproc library from the 64bit targeted .net application.
Probably the easiest thing to do is just set your main executable to be x86. Its the application that will determine how the rest of the assemblies are jitted.
None of the above worked for me. BUT what you can do is when you click 'Add Reference' select the relevant reference via the COM tab rather than browsing to the DLL. This makes it version specific, so if you select 32 bit version, runtime will go with that. Also, be sure you have selected relevant .NET framework version for application pool and you may want to set 'Enable 32 Bit Application' to true (advanced application pool settings).
Related
I'm using PDFCreator to create PDFs in VB6. My VB6 development VM is Windows XP 32-bit. On that system PDF generation works both from a desktop app and from ASP (via VB web class runtime).
When I create an exe to run on Windows 7 or Windows Server 2008 R2 or use it in the web class runtime I get:
Run-time error '429':
ActiveX component can't create object
This is when using early binding. I add a project reference to "C:\Program Files\PDFCreator\PDFCreator.exe" and then in my code I do:
Public WithEvents mPDFCreator As PDFCreator.clsPDFCreator
Set mPDFCreator = New PDFCreator.clsPDFCreator
If I don't use a project references and use late binding instead, then it works on the desktop app but still not in the web class runtime. Late binding is done like so:
Set mPDFCreator = CreateObject("PDFCreator.clsPDFCreator")
I want to use early binding so that I can use the events, plus I need it to work in ASP/Web Class Runtime.
I realise I'm dealing with ancient technologies here and I should have tempered expectations when running such things on modern 64-bit Windows and IIS. If porting this legacy app to .NET were an option, I would.
On IIS I have set the Enable 32-bit Applications setting on my app pool. I have also tried running it as Administrator to rule-out security problems.
I've done everything I know how to debug this, but I'm stumped. I suspect it has something to do with PDFCreator being a 32-bit app and COM registration. I've also tried running regsvr32 out of SYSWOW64 but PDFCreator.exe can't be registered.
Windows 64-bit architecture does not allow the load of 32-bit dll into 64-bit processes.
But you can modify the configuration of your vb project to convert it from an in-process dll COM component into an out-of-process exe COM server. This will allow you to instantiate your 32-bit component from a 64-bit process.
See Process Interoperability
Since this is a VB6 question there aren't any 64-bit processes to worry about.
It seems far more likely than anything else that this library just isn't being registered properly. I haven't use it since I don't know whether its setup works properly. I do know that the download itself does not display with a UAC Shield on its icon, suspicious in itself. For all I know the setup program spawns a run of the wrong regsvr32.exe.
But it seems more likely you have misregistered the library manually after copying it naked over to these 64-bit Win7/Server 2008 systems.
In any case, going over all of the symptoms you describe, I'd guess it got registered as a 32-bit ActiveX library but registered in the per-user virtualized part of the registry for the user you were logged on as when you registered it.
This can be a hassle to clean up after. However you should, and then be sure to manually run the original setup once again with elevation.
These threads that include hand-wringing over "ancient technologies" really get old. It's a poor workman who blames his tools. In the future why not hire an experienced programmer to handle tasks like this?
I use PDFCreator in my accounting software written in VB6. Years ago, I noticed that after a certain update from the makers of PDFCreator, my software stopped working properly with it. The problem stopped after I re-installed the older version, and came back when yet another new update was released from them, so I have had my customers freeze at the version that worked. I don't know off the top of my head what version that was, but I can check my own web site since I made it downloadable for my customers if it would help, but it's likely many years old now.
I am using 0mq with clr binding - version 3.2.2 - on Windows OS. On one particular Windows 7 64-bit system, 0mq always fails at the time of creation of a new Context. I initially thought it had something to do with windows services / IIS but it fails even for a simple console application
Error message below
Assertion failed: Connection timed out (..\..\..\signaler.cpp:260)
External component has thrown an exception.
Last error code (I am calling GetLastError from C#) is 10060 (which is connection tiemout)
Code below
var ctx = new Context(1);
I have checked the following links and tried the suggestions but no luck
http://grokbase.com/t/zeromq/zeromq-dev/126jmgg0aq/sehexception-when-calling-zmq-init-from-clrzmq
https://github.com/zeromq/clrzmq/issues/81
Calling Win32 CreateEvent() fails from an IIS 7.5 web application
I have tried the following
Used dependencychecker and ensured all referenced DLLs are present
Ensured VC++ 2010 runtime is installed
The account under which the console application ran has administrator privileges and I also gave explicit permissions to create global objects (one of the suggestions) in user account management
I am baffled by this bug. 0mq has worked great so far and I wanted to deploy it on a larger scale. Now this error is giving me second thoughts on the same. Any help will be greatly appreciated
It looks to me like your app isn't finding the appropriate ZMQ DLL. A couple things to check:
Make sure that libzmq.dll is in the same directory as your exe.
Make sure that you know whether libzmq.dll is 32 or 64 bit.
Make sure that you've explicitly specified an architecture in your C# Project File (either x86 or x64, not AnyCPU), and that the architecture you pick matches the architecture of the libzmq.dll file you're using.
I'm working on an application developed for Windows XP SP3, using VB6. I'm currently in the process of getting it to work on Windows 7, but am encountering a problem with one of our custom OCX files.
When attempting to load a form that contains an instance of the control contained in the problem OCX, the following error is produced:
Failed to load control 'x' from y.ocx. Your version of y.ocx may be outdated. Make sure you are using the version of the control that was provided with your application.
I've checked the version numbers and they're all correct and referencing the proper version. The OCX registers fine, and all the expected registry entries are present.
Inspection with DependencyWalker shows no missing dependencies.
The software works fine under XP, and this is (seemingly) the only issue when running on Windows 7.
Interestingly, if I run through the VB6 IDE using a VB6 group (with the offending OCX part of the group, and the application the startup project), I don't have the issue. Running the application on it's own through the IDE still presents the error.
Any ideas on what could be missing which would cause the application to throw this error?
Error occurs on both Windows 7 Professional and Home Professional, both 32 bit.
This is almost certainly an interface compatibility problem. COM interfaces are versioned entirely separately from your Major/Minor/Revision numbers, which are little more than comments except as used by Installer.
Somewhere along the line you broke binary compatibility, and you are trying to deploy a library with a newer interface than your application was compiled against.
These version numbers are found in keys such as:
HKEY_CLASSES_ROOT\CLSID\{class Id GUID}\VERSION
Your program needs to have its old reference to the OCX removed, a new one set, and then it must be recompiled. This also means deleting any instances of the control and adding them back one by one.
I doubt this is a Windows 7 issue.
I would suspect this is a UAC problem. Try turning UAC off to see if that solves the immediate issue. If it does then you have to regsiter everything using 'run as administrator' and/or create a manifest for you application.
Sounds like on of the controls included in your OCX is having issues loading, not a general registration error. Look at the constructors for x control, and see if they are doing anything that disagrees with UAC or such. One way you can debug this is put some kind of a break before the control is initialized, and debug the application from Visual Studio (remember to create the PDB's in VB6), and then carry on from the break to see why the control isn't initializing.
When try to debug the VB dll Using Visual Studio 6.0 , I am getting the the following error. Can you any one tell me what needs to be done for this?
System Error &H80004015 (-2147467243).
The class is configured to run as a
security id different from the caller
I have had the same problem.
Created a few ActiveX DLLs and put the binaries into a COM+ Application, which runs under a specific account (not mine). Then I use these components inside ASP script pages using Server.CreateObject().
If I load the source code into VB for debugging and try to run it ("Start with Full Compile") I get this error message.
The cause of this is that the account registered in the COM+ Application differs from my own account from which I try to run.
Solution for this particular case is to Shutdown the COM+ Application and remove the components. When finished debugging, compile the set of DLLs and put them back to the COM+ application.
Hope someone is helped by this :-)
My solution was to unreference the dll in the Visual Basic project (Project Menu -> References), close the dialog box and reference it once again. I ran the project and everything is working again. I did not have to edit the windows registry.
There's a knowledge base article that seems to apply to your situation:
PRB: System Error Message "&H80004015" When You Run ActiveX DLL in Visual Basic IDE
Cause: When Visual Basic runs an ActiveX DLL from the IDE, it calls the CoRegisterClassObject application programming interface (API) to temporarily register the server. This creates the AppId and specifies it to run in the Interactive User context.
This problem occurs because of a bug in the Microsoft OLE Libraries 4.0, which are included with the Microsoft Platform Software Development Kit (SDK). CoRegisterClassObject fails with the error message that is listed in the "Symptoms" section of this article under the following conditions:
If the ActiveX server that calls the API is set to run by using the Interactive User identity.
-and-
The string that is associated with the following registry key contains any value other than a single valid executable name for the shell process:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Shell=
Under Microsoft Windows 2000, this error occurs when the Certification Authority service does not start.
Resolution: Make sure that the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Shell= registry key contains a single valid executable name for the shell process.
To resolve this problem under Windows 2000, you can install the "Client for Microsoft Network" component and then reboot.
I have a windows forms (.net 3.0) project that won't run on my customer's vista computer due to a DEP error. It runs on my vista machine, and in a clean version of vista sp1 in a virtual machine. I am having trouble tracking down ways to make my program DEP, Data Execution Prevention compatible. I really can't do anything to end user machines, it just has to run. Is there any way out of this latest vista development nightmare? My program uses devexpress controls, sql express, and the .net ie web browser control. I've already jumpered out the ie control, but to no avail. I have other program that use devexpress and sql express on that same machine and they run ok. I am at a loss to debug this on the user's computer.
DEP runs in one of two modes:
Hardware DEP is for CPUs that can mark memory pages as non-executable. This helps to prevent certain exploits such as buffer overflows.
Software DEP is for CPUs that do not have hardware DEP support. It doesn't prevent execution of code in data pages, but instead stops SEH overwrite (another type of attack).
On Windows XP with CPUs that support it, hardware DEP is enabled by default only for certain Windows system binaries, and also for programs that choose to "opt-in".
On Vista with CPUs that support it, hardware DEP is enabled by default for nearly all processes. This can occasionally be problematic, usually for older programs and drivers, and for ISVs that haven't done any Vista testing.
So I suspect that the first step is to discover whether you're dealing with software or hardware DEP. Also, are you using C#/VB or Managed C++? And are you using any native code or components? If your application uses a native component or an ActiveX control that was built using the old ATL framework, then it's quite possible that your application will fail with hardware DEP.
Since .NET Framework 2.0 SP1, I believe that the C# compiler emits managed code which is DEP-compatible. But if your application is generating DEP exceptions, then you can try clearing the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag for your executable. To do this you use EDITBIN.EXE from the VC toolset like so:
editbin.exe /NXCOMPAT:NO <your binary>
If you're using Visual Studio, you can add a post-build step to your executable's project. You'll need to setup the environment so that EDITBIN's dependencies can be resolved. When I'm using native code as part of my app, the post-build step looks like this:
call $(DevEnvDir)..\tools\vsvars32.bat
editbin.exe /NXCOMPAT:NO $(TargetPath)
The compilers that shipped with .NET 2.0 SP1 turn on the NXCOMPAT flag in the executable file header. You can turn that flag off in a Post Build step by running EditBin.exe with the /NXCOMPAT:NO option.
Older versions of ATL are not DEP aware, so if you use any ActiveX controls built using ATL and were built on that version of ATL (version 7.1 and below, I think), you'll get DEP errors.
As a last resort, you can disable DEP for the process by calling an API function: SetProcessDEPPolicy.
More information on SetProcessDEPPolicy.
FWIW, it's worth explicitly mentioning that in many cases, applications aren't "incompatible with DEP" but rather were about to crash anyway and DEP "dove in to save the day." Very often, once you disable DEP, you'll find that you're hitting an "ordinary" AV.
If your project is written solely in .NET 3.0, this is almost certainly the case, because .NET doesn't do any of the "crazy" things that trigger DEP (e.g. function thunking, etc).
To debug, install a debugger or enable Watson to generate a .DMP file, then take that .DMP file to the developer's machine and figure out what went wrong.
Start by trying to figure out where and how your program is failing. Can you replicate the issue on your system? With enabling DEP for the application on your system? When you can replicate the issue and get the error (access violation), you can look to fixing your program.
See the MSDN article for information on DEP.