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.
Related
I seem to be able to access the functions in C:\WINDOWS\system32\opengl32.dll (and likewise C:\WINDOWS\system32\glu32.dll) from either a 32-bit or a 64-bit application (for what it's worth, I'm doing this from separate 32-bit and 64-bit Python 2.7 interpreters, via the ctypes module).
With glut32.dll, things are different. It only happens to be on my Path as part of a 32-bit installation of GraphViz. From 32-bit Python, I can link dynamically to it, but from 64-bit Python I get [Error 193] %1 is not a valid Win32 application.
Now, this error does not surprise me, because I had always thought DLLs were obliged to commit to one architecture or another on Windows (in particular, this recent question and its answers seem to say so). What surprises me is the lack of an error in the first case... How does opengl32.dll do it, and how can I replicate this behaviour when building my own DLLs?
On 64 bit system only 64 bit processes use c:\Windows\System32\opengl32.dll. For 32 bit processes system redirects c:\Windows\System32\opengl32.dll to c:\Windows\SysWOW64\opengl32.dll.
File System Redirector
In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64. Access to %windir%\lastgood\system32 is redirected to %windir%\lastgood\SysWOW64. Access to %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe.
Problem
I have a Windows application that we developed for in house use. Thanks to Windows Error Handling, the window stays open and I can easily generate a crash dump from the task manager.
I have used crash-dumps on linux through eclipse once before, but this is the first time on Windows.
Hardware
The server is Windows 2012, and my development machine is Windows 7.
Windbg
When I load the crash dump in Windbg, load my symbols, then choose to look at the call stack, the only listings are:
How can I see my application call stack specifically?
Looks like your applications is a 32Bit application and you used the 64Bit Taskmgr to generate a dump.
You should use ProcessExplorer instead, it cares about the bitness:
Process Explorer v15.3: It also creates dump files that match the
bitness of the target process
Or run the 32Bit Taskmgr from C:\Windows\SysWOW64 to generate the dump.
As already answered, you have taken a 64 bit dump of a 32 bit application. There are multiple options to take a 32 bit dump of a 32 bit application on 64 bit OS, just choose the one which is most comfortable to you.
If this is the only dump you have and there's hardly a chance to get a better dump, you can try !sw to switch to 32 bit mode:
0:014> !sw
Switched to 32bit mode
0:014:x86>
Note how the command prompt changed. IMHO the exact same effect can be achieved by .effmach
0:014> .effmach x86
Effective machine: x86 compatible (x86)
0:014:x86>
except that you specify the mode explicitly where the !sw command toggles between the two.
In case of a .NET application, none of these ever helped me, since SOS cannot work with dumps of incorrect bitness.
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.
I have a little trouble with windows 64 bit registryget. It does not work on powerbuilder 8.04, and I cant figure it out why. If someone have any suggestion, please let me know.
Though "does not work" is not a very precise description of the problem, i guess it is probably because PB programs are 32 bit, so the registry access is virtualized for HKEY_LOCAL_MACHINE into HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node so the PB application does no "see" the 64 bit part.
You can check what PB has access to by using the 32 bit regedit that should be located in C:\Windows\SysWOW64\odbcad32.exe
And if you actually need to manage 64 bit registry from PB, you could declare the native RegOpenKeyEx api function as a local external function and access explicitely to the KEY_WOW64_64KEY as described in this answer.
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).