Hi I have a vc++ application, earlier it has target platform for 32 bit application, it was fine in all aspects (debugging, build, execution).
Now I want to port the same application to 64 bit target environment, which I complied it without any issues, but NOT ABLE TO DEBUG the application, breakpoint never hit anywhere, are there any settings( project/debug) specific to 64 bit target, which I need to modify,
And also I didn't find any information related to 64 bit debugging for VC++ application on internet.
Please someone help me with this!
thanks,
Palaksha
Related
I'm trying to run an exe which calls Microsoft.ACE.oledb.12.0 but get the error "Provider not registered on local machine". There has been quite a lot about this error on Stackoverflow. Recommendations to correct this are to install AccessDatabaeEngine and compiling in x86. I've done both and although the path in project is set to x86 I suspect it is still compiling to 64 bit as VS continues to place the exe in that 64 bit folder. But I 'm at a lost as to how to correct this. Any one know how to fix this or confirm if the exe is 32 or 64 bit regardless of which folder it is placed in. Running vs2012 on windows 2012 server 64bit (Hyper-v)
regards
Erick
ok...so this is what happened. I changed the cpu type to x86 on the project properties. Which did compile to 32bit but placed it in the incorrect folder. I confirmed this by opening the exe in notepad as there is a way to tell what type it is.
However, the debug version remained at 64 bit. The fix is to use the drop down list on the toolbar which says "Release" or "Debug" and set it to Configuration manager. In there set both the release and debug values to x86. This compiles it to x86 and puts it in the correct folder. I don't know how this is different but it now happily uses the 32 bit dll.
Long story, so please bear with me.
I have an app that I wrote back in 2001 for an AS400/iSeries ISV. Basically, it takes drawing commands off of the AS400, and creates a windows graphic (bmp) file so that they can then display the graphic in their application. Everything has worked great over the years. Now, they have a new customer that is having problems running the application. The problem is that when my application is called from the ISV's software, windows generates a message stating that the application is a 16 bit application and can not be run. I am sure that the application is a 32 bit application. We have tested this on 3 machines running Windows 10 x64 at the ISV's office and do not get the error. We get the graphic and everything runs as intended.
I am guessing that the problem is that the WOW64 layer is somehow not enabled or not setup. Questions:
I thought that VB6 apps were all 32 bit. Is that correct?
Is it possible to not install the WOW64 layer during a Windows setup?
Is it somehow possible in Windows 10 x64 to not enable 32 bit apps?
If you have any other suggestions, we are glad to hear them.
TIA and for your time.
Wally
I am upgrade my 32 bit sample Voip application to 64 bit. After upgrade my application .exe file give a problem:
The application was unable to start correctly (0xc000007b)
My PC is 64 bit. and i build it in 64 bit
I realize this is probably late for you, but for anybody looking at this question, the problem is that you have a mixture of 32-bit and 64-bit components (DLLs) that are loaded at start-up. Since your app is built as 64-bit, you probably still have some 32-bit DLLs that the system attempts to load in the process and fails (since 32-bit modules cannot be loaded in a 64-bit process).
I have a WPF 4.0 application that I have compiled for x86. When running on 64bit Win7, I need to start up an on-screen keyboard, located in %windows%/System32/osk.exe. Problem is I can't do it- I get an error 'Could not start On-Screen Keyboard'.
I found this thread:
Unable to launch onscreen keyboard (osk.exe) from a 32-bit process on Win7 x64 which sounds exactly like my problem.
I used all the relevant bits from that post, but the error persists. And even worse, I managed to get a 32 bit version of osk.exe and when I try to start THAT I just get a blank error box- no message at all, just a red 'X'.
So I can't compile my app for AnyCPU (3rd party interop libs), and have read that that might not solve the issue anyways. I have also read that one workaround is to disable virtualization using Wow64DisableWow64FsRedirection, but that this is unsafe. Seems like a lot of effort just to run a little app :(
What can I do to launch this little thing from my app?
Wrapping the offending app in a exe compiled with AnyCPU works fine and seems to be the least painful approach.
I know that there are issues with the VFP OLEDB provider on 64 bit machines. ... but what issues do you encounter while actually running a VFP application - on a 64 bit machine? Has anyone had any experience in this area?
My first thought was that it would just run as a 32bit app, without making use of the 64 bit power. However, I ran into difficulties with a FoxPro application connecting to a SQL Server database (probably an OLEDB issue as well). Are there other issues as well?
This is somewhat of a specialized scenario, and it may not be related to 64 bitness, but since you asked...
My organization recently hosted a legacy VFP 7 app on a Windows Server 2008 Enterprise 64 bit server for access over Terminal Services. The app runs fine, but there is some kind of bug with the TS Easy Print technology. When you print from the app to a redirected client printer over Easy Print, the top, left, and bottom sides of each page of the document get clipped. The workaround we use is to have the users print to pdfFactory on the server first, then print from pdfFactory to the redirected client printer over Easy Print. Works great.
This is somewhat of a stab in the dark...but I believe there are some drivers with MDAC that aren't available in x64 windows. I think you may be able to install the normal 32-bit MDAC but it will install to the x86 folder.
We've seen zero problems with our VFP9 apps on 64-bit XP, Server 2003, Vista, or Server 2008.
Our print engine is a VB DLL though, so we wouldn't run into any VFP-specific printing issues.