Have been reading a lot about this one and the picture just gets muddier. I have a 32-bit app that installs a KeyboardHook to wait for a global hotkey and wake up. Running it on Win 7 x64 edition I notice it hangs Outlook x64 edition when the hotkey is pressed.
So I did some research and it looks like 32-bit keyboard hooks aren't even supposed to work in 64 bit apps. Time for more testing...
They hotkey works fine in 64-bit notepad, wordpad, and sticky notes. I verified that these are 64-bit apps since they don't have "*32" next to them in Task Manager. Doesn't hang the app and it does what it's supposed to. But wait... a 32-bit hook dll can't be loaded into a 64-bit app, right?
A look at Process Explorer shows the hook dll isn't even loaded into the notepad process! (If I run the 32-bit notepad.exe from WOW64 directory, I can see the dll loaded into the process, so I know I'm using the tools right).
So the Outlook hanging issue might or might not be related, but why is the hook even working at all in 64-bit notepad?
I have a 32-bit app that installs a KeyboardHook to wait for a global hotkey and wake up.
If that's your ultimate goal, then it's simpler and less of an impact on the system to just use RegisterHotKey.
Related
Strange configuration which I can't seem to understand.
I have a Windows Phone 8 library that I want to build for Any CPU, this works fine when I am selecting Debug, but soon as I choose Release configuration changes the platform to x86.
I can change it to Any CPU, save and exit options but if you open it again it is switched back to Active (x86).
What do I miss? The proper way to distribute Windows Phone libraries?
Regards.
Greetings for the day.
I am having a issue making my 64bit ActiveX component to run on Win8(64Bit) over IE10(64bit) browser.
ISSUE:
I am having a 64bit Intranet application in which I have an ActiveX component (COM .dll) which creates an explorer bar and a BHO in Internet Explorer.
I am trying to use this ActiveX Component in Win8 (64Bit) and IE10.
What works for me:
My 32 bit ActiveX version in Win8(64Bit\32bit)\Win7(64bit\32Bit) using IE10 without EPM enabled.
My 64bit ActiveX in Win7(64bit)\Win Server 2008 R2(64bit) using IE7\IE8 (64 bit).
My 64bit ActiveX in Win7(64bit) using IE10 having EPM enabled.
What does not works for me:
My 64bit ActiveX component in Win8(64bit) using IE10(64bit) having EPM enabled.
Having read all the blogs available over the internet, I learnt that for a 64bit ActiveX component to work in Win8(64bit) using IE10, I need to enable EPM(Enhanced Protected Mode) , register both 32bit and 64bit versions of my ActiveX and also my ActiveX should be EPM compatible. Also my dll should be located in AppContainer readable folder like Program Files.
Blog Links:
http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx
http://www.askyb.com/bho/step-by-step-guide-to-making-you-bho-epm-compatible-with-ie11-on-windows-8/
What I have tried So far:
Made my ActiveX component EPM compatible according to the above links.
(My ActiveX dll has 5-6 classes and different .rgs files for registering each. So I added the AppContainer GUID in a separate .h file and included that file in each class .cxx file. Also included the
‘Implemented Categories’ in all .rgs file.)
Registered both 32bit and 64bit versions of my ActiveX.
Enabled the EPM.
Now I am able to get only my explorer bar enabled with EPM. But other BHO functionality is not working.
One of the functionalities of my ActiveX is that it reads the Machine Name and returns it. But in Win8(64bit) using IE10 it is not working even after doing all of the above.
Bottom-line is that my ActiveX is not working completely as expected,ie., The instance of one of the BHO Component(which is used to read the clients Machine Name) is not getting instantiated as expected,same Component works fine with a 32 bit BHO Component on the same Environment :(
Is it something I did wrong in making my ActiveX component as EPM compatible?
As I want my application to run only in 64bit mode as it’s an intranet application, do I still need to register both 32bit and 64bit versions of my ActiveX?
Should both the 32bit and 64bit versions should be made EPM compatible?
Should both 32bit and 64bit have the same CLSID?
Any quick solution would be greatly appreciated, Since I’m going nuts working on this issue from past few days, hoping for a positive response from your guys.
Thanks in advance
When starting the debugger, Visual Studio just hangs for about 20 seconds, then terminates the debugging session, without any warning.
The 32-bit version works fine, but is no good if our plugin uses 64-bit native code from a third party.
As a developer, I'm sticking with Petrel 2012.1 on my workstation for the time being - might the issue be fixed in a later release?
It's not a bug but a feature – the license protection mechanism. But you can attach your debugger to Petrel 2012.1 64 bit when Petrel's UI is visible, the initial steps only are protected from debugging.
But of course you would still need to use 32-bit version of Petrel if you want edit-and-continue while debugging: Why doesn't Edit and Continue work on the x64 CLR?
I have activex server exe that was building and registering fine on 32bit OS. I wanted to make 64 bit version of that exe by upgrading project to Visual Studio 2010 and changing platform to X64 which apparently doesn't work.
Application itself works but I don't see it registered after running
That.exe /RegServer
I would appreciate any usable advice on migrating activex from 32 to x64.
Code that is processing /RegServer param is below:
if(lstrcmpi(lpszToken, _T("RegServer")) == 0)
{
_Module.UpdateRegistryFromResource(IDR_OUTDISKSARG, TRUE);
nRet = _Module.RegisterServer(TRUE);
bRun = false;
break;
}
32 bit activex is unuable for me since I have to load it in x64 .NET process.
Assuming that the process has enough rights to write to the registry, you'll have to take care of that by running it from an elevated command prompt, this is likely to only add the COM registry keys to the registry view that 64-bit processes can see.
32-bit COM clients get a different view of the registry, HKLM\Software\Wow6432Node. It is not going to find the registry keys there. Review RegCreateKeyEx() in the SDK docs. Note the link at the bottom and the talk about the KEY_WOW64_32KEY option. The online article is here.
32-bit clients accessing a 64-bit out-of-process COM server is otherwise a pretty well supported scenario, with some caveats. Like building and registering both the 32-bit and 64-bit proxy/stub DLLs.
When you run That.exe /RegServer, did you do that from an Administrator command prompt? If not that's probably why it didn't work.
If you did and it still didn't work, try debugging it to see what it's doing to the registry. e.g. Use Process Monitor, or even the Visual Studio debugger (remembering to ensure the debugger runs your app as admin).
I developed an application for a local company that required printing a chart and some data. I made the program on a Windows 7 machine using the PrintForm control. It printed just fine and I sent it to the company, but they are running it on WindowsXP and the program is crashing. I assumed that PrintForm would work on all Win operating systems but apparently that is not the case?
If there is something special that needs to be done to get PrintForm to work on XP that would be fine (downloading a lib file or something), but otherwise what is the best way to print out a VB.NET form on Windows XP?
Thank you!
My guess is they don't have the Microsoft.VisualBasic.PowerPacks.VS.dll on their PC's. You need that to be included in your deployment project so they can call PrintForm.
I don't think this is unique to XP though. According to MS, this has been a feature ported from the early VB days.