I try to create a COM object from my JS script like this:
function main()
{
var MyApplication = new ActiveXObject("Base.Application");
}
main();
I am getting error: "Automation server can't create object". This error occurs on Windows 2003 64 bit. The dll is 32 bit and it works fine on 32 bit systems.
I've tried both versions of Regsvr32.exe on the 64 bit system and both versions told me that dll registered succesfully.
Unfortunatelly the error message does not tell me why it can not create object. The reason is unknown, it might be that it can't create object because it is still not registered or it might be something totally different...
I've also add full permisions to this dll.
I don't know what else I can do, do you have any ideas?
After edit
Ok, I know that this DLL is registered under system (found it at the registry), so why I can't call any COB objects from it?
Maybe because your process is 64 bits and you try to call in a 32 bit dll? (There are some tricks though, in this case like the one described here).
Related
I am trying to run a legacy Win32 app built with Delphi5 on Windows 10 64 bit. There are some COM objects in the form of dlls that need to be loaded at start up. However, when I try to load them, most of the time, not always though, the call in CoCreateInstance gets stuck indefinitely. I mean it just sits there. Sometimes, the objects are instantiated correctly and software does start up, so I believe registering isn't an issue. This only happens on Windows 10, on my WIndows 7 64 bit PC, it never happens.
I have isolated the problem CreateComObject in ComObj.pas, but this may just be misleading because in the end it is the call the CoCreateInstance that never returns.
function CreateComObject(const ClassID: TGUID): IUnknown;
begin
OleCheck(CoCreateInstance(ClassID, nil, CLSCTX_INPROC_SERVER or
CLSCTX_LOCAL_SERVER, IUnknown, Result));
end;`
BTW, I tried setting the ThreadingModel to different values in registry but that doesn't seem to solve the problem.
Does anyone have any idea how to resolve this? I would really appreciate any feedback as I am out of ideas at this time.
I am a newbie to Windows device drivers. My immediate task is to take an existing 32 bit minifilter driver and port it to 64 bit Windows. My development environment is Windows 7/64 bit, Visual Studio 2012 Ultimate, DDK 7600.16385.1, and SDK 7.1A. The install package is a setup.exe created with InstallShield 2013.
I've found some doc on porting drivers to 64 bit, but it's all about code issues. I haven't been able to find an idiot's guide covering step-by-step instructions for everything else you might have to change, so I decided to take the naive try-it-and-see-what-happens approach and just recompile for 64 bit, with the one exception to that being code signing since I did read somewhere that Win64 requires signed drivers.
The pre-existing build for the driver project used DDKBuild.cmd, and I have modified the properties for the Win64 platform to specify ../scripts/build.cmd -WNETAMD64 free $(OutDir) on the build command line. The compile and link are successful. I've modified the InstallShield project to pull in the signed 64 bit code file instead of the 32 bit code.
The installation appears to run successfully on a 64 bit system (Win2008 R2). There's a two line script that runs during the install:
rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 .\xxxxxflt.inf
fltmc load xxxxxflt
The rest of our application is actually Java, which makes some JNI calls to a couple of DLLs, one of which calls FilterLoad(). (BTW, the JVM and the DLLs remain 32 bit, but my understanding is that 32 bit code should be able to load a 64 bit driver via FilterLoad(). Please correct me if I'm wrong.) The return from FilterLoad() was ERROR_FILE_NOT_FOUND, and that caused me to notice that, as stated above in the question, the xxxxxxflt.sys file had been copied into SysWOW64\drivers instead of System32\drivers.
I know this is wrong, because Win64 is oppositeland, so System32 is where 64 bit stuff should go and SysWOW64 is where 32 bit stuff should go. What I don't know is why it ended up there. Are there changes necessary in the .inf file in order to identify this as a 64 bit driver? Is there anything I might have to do in the InstallShield project to tell it to build a 64 bit installer or run scripts in a 64 bit engine? Does the script have to do something to force use of the 64 bit version of rundll32? Something else, perhaps?
I haven't seen this specific problem, but I've had issues with this type of "WOW64" thing before. It usually means there is something within your software that is 32-bit and is being run in that mode, so anything you do will end up in the a "Program Files (x86)" or "WOW64" type location. Here is what I think might be happening:
This could have something to do with the way you are calling rundll32.exe. See the following post:
rundll32.exe equivalent for 64-bit DLLs
It's possible that if your InstallSheild installation is creating a 32-bit executable then it is running in WOW mode already which means that it's probably choosing the rundll32.exe that is in the WOW directory, thus the reason your installation ends up there too.
You might look at modifying your script to call the specific one based on the platform, or see if you can change your InstallShield to run as a 64-bit application in non WOW64 mode.
The 32-bit version of our app is unable to send email using MAPISendMail with 64-bit Outlook installed. It returns an error 0x80004005, about which I can find little information beyond the fact that it seems to be a MAPI initialization error.
According to this MSDN document, MAPISendMail is the one exception to the rule that 32-bit apps can't use 64-bit MAPI. And yet it doesn't work (at least with XP and Vista--we haven't tested Win7/8 yet).
Can anyone shed any light on this?
TIA
There are no exceptions: a 32 bit process cannot load a 64 bit dll.
When you have the 64 bit version of Outlook, the 64 bit version of mapi32.dll contains the actual implementation. The 32 bit version of mapi32.dll is a stub that does nothing but return an error.
That's not completely true #DmitryStreblechenko, - at least not for the MAPISendMail function. For that, and only for that, it is possible to build a "Outlook64 Bridge". This will then redirect 32bit MAPISendMail calls to 64bit Outlook. That bridge may look like:
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Outlook64Bridge]
#="Outlook64Bridge"
"DLLPathEx"="c:\\Windows\\winsxs\\x86_microsof t-windows-mapi_31bf3856ad364e35_6.1.7600.16385_none_ab239772 7b134496\\MAPI32.DLL"
"DLLPath"="c:\\Windows\\winsxs\\x86_microsoft-windows-mapi_31bf3856ad364e35_6.1.7600.16385_none_ab239772 7b134496\\MAPI32.DLL"
IMPORTANT, - you have first check to correct path of your 32bit mapi32.dll!
After adding these lines to the reg you have to set the Outlook64Bridge as your default mail client by:
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail]
#="Outlook64Bridge"
It is confirmed to work for simple 32bit applications which use really only the MAPISendMail function.
More information can be found here
Years ago I'had the same problem. I tried and tried again, but no way ... Microsoft blocked some interactions between 32 bit and 64 bit application: you can't even use 64 bit OCX/OLE in a 32 bit application.
The Outlook Bridge solution above (#VMAtm), worked in the beginning, then Microsoft fixed it, and it stoppend working.
In the end I realized a 64 bit application, my bridge application, to connect main 32 bit application with 64 bit outlook:
Main 32 bit application is running ...
Main 32 bit call bridge 64 bit application; mail data (from, to, title, body ...) are stored in a xml-file. The xml file is passed via command-line.
64 bridge applicatio starts, and call MAPI functions.
64 bit outlook does the rest.
This solutions works fine, and I'm quite sure I don't have to struggle with MAPI libraries.
My app uses LoadLibrary to load plugins at run-time and users can accidentally try to load 64 bit plugins in the 32 bit version of my application.
It looks like the error code returned from LoadLibrary is not very descriptive (says "%1 is not a valid Win32 application").
I am looking for ways to figure out if the plugin dll file is built 32 or 64 bit so that I can notify the user in a user friendly way.
Any ideas?
In order to retrieve information about an image such as the one you are looking for, just use the ImageHelp API
I encounter an access violation when calling a DLL inside LabVIEW. Let's call the DLL "extcode.dll". I don't have its code, it comes from an external manufacturer.
Running it in Windbg, it stopped with the message:
(724.1200): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!RtlNewSecurityObjectWithMultipleInheritance+0x12a:
And call stack is:
ntdll!RtlNewSecurityObjectWithMultipleInheritance+0x12a
ntdll!MD5Final+0xedfc
ntdll!RtlFindClearBitsAndSet+0xdf4
ntdll!RtlFindClearBitsAndSet+0x3a8
ntdll!RtlFindClearBitsAndSet+0x4b9
ntdll!RtlCreateProcessParametersEx+0x829
ntdll!LdrLoadDll+0x9e
KERNELBASE!LoadLibraryExW+0x19c
KERNELBASE!LoadLibraryExA+0x51
LabVIEW!ChangeVINameWrapper+0x36f5
LabVIEW!ChangeVINameWrapper+0x3970
LabVIEW!ExtFuncDynLibWrapper+0x211
Note that dependencies of extcode.dll are loaded before access violation.
The situation is random, but when it happens all subsequent tries lead to it.
The code is a simple LabVIEW function calling a function in the DLL, and prototype is super simple (int function(void)) so it cannot be an misconfiguration of the call parameters, nor pointer arithmetics. I checked every combination of calling conventions and error checking levels.
The DLL runs perfectly fine when called in other environments (.NET and C).
I found that RtlFindClearBitsAndSet is related to bit array manipulations
What does it make you think about? Do you think it is a problem in extcode.dll, LabVIEW, or Windows?
PS: I use LabVIEW 2010 64 bit, on Windows 7 64 bit (and extcode.dll is 64 bit). I didn't manage to reproduce it on 32 bit system.
11/18 EDIT
I ended up making a standalone exe that wraps the DLL; LabVIEW communicates with it through pipes. It works perfectly, but I stil don't understand why loading a DLL into LabVIEW can crash.
If it works ok when called from C, you can quit working with Windbg because the DLL is probably ok. Something is wrong with how the DLL is being called, and once the DLL overwrites some of LabView's memory it is all over, even though it might take 1000 iterations before something actually goes kablooey.
First check your calling conventions, C or StdCall. C calling convention is the default and StdCall is almost certainly what you want. (Check the DLL header file.) LabView 2009 apparently did some auto-checking and fixing of calling conventions, but the switch to LLVM in LV 2010 has made this impossible; now it just tanks.
If it still tanks after changing this, check your calling arguments again. what you are passing, scalars or pointer data? You cannot access memory allocated by the DLL from LabView without doing some sneaky things, although you can allocate memory (i.e. byte array) in LabView and pass a pointer to it to the DLL for it to modify.
Also, if you are getting a pointer (such as a refnum) from an earlier call to DLL and returning it, check your pointer size. LabView's Call Library function now has a "pointer size integer" type, which generates the appropriately-sized type depending on whether it is invoked in 32-bit or 64-bit LabView. (It is always 64 bits on the wire, because that has to be defined at compile time.) The fact that your DLL works in 32 suggests this is a possibility.
Also keep in mind that C structs are often aligned by the (C) compiler. If you are passing a pointer to a struct made of a Uint8 and an UInt16, the C compiler will allocate 32 bits (or maybe even 64 bits) for this. You'll have to pad your struct (cluster) in LabView to make it match, or write a wrapper DLL to assemble the struct.
-Rob
An access violation (0xc0000005) will also be reported if DEP (Data Execution Prevention) is enabled on your machine and disapproves of something your binary (EXE or DLL) is trying to do. DEP is usually off by default on Windows XP, but active on Windows Vista / Windows 7.
DEP is a hardware-supported security measure designed to prevent malicious code executing some bytes that previously were considered "just some data"; I've had a few run-ins with it, all of which required re-compiling the offending binaries with a recent version of Microsoft Visual Studio; this allows to you set a flag which defines whether or not your binary supports DEP.
Some useful resources:
I found this MSDN blog entry
very helpful for gaining an
understanding of what DEP is and does
You might also want to consult this
technet article on how to turn
DEP on and off on Windows XP.
This is hard to diagnose remotely, but here are a couple of ideas.
The fact that your function takes no arguments means that either the function is truly trivial, or there is some stored state in the dll that takes into account previous function calls. Maybe the crash in this function is only an indicator, and you have a problem with a previous function call? Is there an initilization routine you're not calling?
If you only have problem when using 64 bit labview, my first guess would be that there's a problem with the 64 bit version of the dll, but if you are sure you don't have any problem with the exact same calls when using the dll in other environments, I'm stumped. One possibility is that you are using the wrong calling convention (stdcall vs. cdecl) in labview.
Have you tried importing the dll and header using the labview import wizard? This might help avoid silly mistakes with the prototypes.
One other thing to try: right click on the DLL call, choose configure and make sure you're running in the UI thread instead of any thread. Sometimes this helps.
When working with git and cygwin under NTFS, i found that sometimes the executable bit is not set (or un-set during checkout or some file operations) - inside cygwin cd to the folder and do
chmod a+rwx *.dll
and check if it changes a thing (and check if you want it this way!). I found this question while searching for LoadLibrary() failing with GetLastError() returning 5 (not "0xc0000005" btw) and solved the issue with this chmod call.