I made a simple application in FASM while using windows vista x86. The application compiled and ran fine with no errors what-so-ever.
I then, moved the same exact source code (literally the same files) to my other PC running windows vista x64. Upon compiling the source code I received errors.
When on x86 I could simply start off with:
include "win32a.inc"
entry start
When compiling on x64 I had to use something similar to the following:
format PE GUI 4.0
include "win32a.inc"
entry start
Another issue (my main concern) is when on x86 I could use:
.if dword [var] = "1234"
;Do something here
.endif
But while compiling the same code on x64 I get "Illegal Instruction" with the following line highlighted:
.if dword [var] = "1234"
Is there a different way to go about doing this on x64?
Also, how can I code to where it will be compatible on both? I figure, if I compile on x86, then the resulting output will run fine on x64?
Finally, is it possible this could have something other to do with than the architecture?
I dug up some old MASM code to use with the latest version of FASM. I had to add this to use the .if macro:
include 'MACRO/IF.INC'
as well as:
include "win32a.inc"
for it to compile. Note I get an Illegal Instruction error without including macro/if.inc.
Maybe the version of win32a.inc on your old 32-bit system includes the .if macro?
Related
I'm trying to code in Visual Studio 2022 17.2.3 on Parallels Desktop (Macbook Pro 14" M1 Pro). The program was built successfully but when it was running, this exception came up:
Unhandled exception at 0x00007FFE6CFD85F0 (msvcp140d.dll) in Test.exe:
0xC000026F: An internal error occurred in the Win32 x86 emulation
subsystem.
I wouldn't call this a definitive answer, but after a load of prune&test'ing with my code; (I had one project that ran fine, and another that didn't) this code alone would cause the exception mentioned above;
#include <iomanip>
int main()
{
return 0;
}
My exception (before main) was here;
cerr.cpp
#pragma warning(disable : 4074)
#pragma init_seg(compiler)
static std::_Init_locks initlocks;
Switching architecture from 64-bit to x86 helped me.
There is likely some error in x64 WinAPI emulation level. On M1 Parallels uses Windows with ARM support, which uses emulation for x86-64 applications.
I assume you are building and debugging an x64 application, so that's the solution I'm posting here. However, the same principle applies to arm64 debugging if you're running into the same problem.
The problem is your path does not include the debug x64 version of the Visual C++ runtime. So the system tries to grab the arm64 version instead, and crashes because the machine code is the wrong architecture.
The simplest way to fix this is to go to the directory containing the Visual Studio non-redistributable debug libraries (something like C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\14.32.31326\debug_nonredist - the exact path is slightly different depending on which version of VS you have installed). Then go to the particular architecture you want (x64 here), then the library (Microsoft.VC143.DebugCRT), then copy the file (msvcp140d.dll) into the same directory as the application you are launching (normally something like bin\x64\debug - check your project settings).
This will allow the DLL loader to find the x64 binary first, and load that up. Then you'll be able to debug your application.
I am trying to step through a C/C++ program (MapServer) in Visual Studio, but I cannot see the local variables.
I created a new project by adding the main .exe I built from source. I can set break points and step through the program without problem, but I cannot see what is stored in any of the variables. I am running all this on a Virtual Machine - the host OS is Windows 10, and the VM is Windows 7.
The program is:
built as a debug release
has no optimizations
the symbols load fine
I am fairly certain it is due to it being a x64 bit release, as I can use the exact same approach for a x32 build and see the variables.
Example of the x32 debugger (the first 5 variables are correct - the others are unset):
Example of x64 debug session (note the program works fine):
I thought it may be due to VS2008, so I also tried in VS2015, but had similar (failing) results:
Trying to access variables in the Immediate Window produces:
// working VS2008 x32 build
map->name
0x00ffcb40 "WFS_server"
// VS2008 x64 build
map->name
0x0000000000000000 <Bad Ptr>
// VS2015 x64 build
map->name
0x0000000000000000 <NULL>
Am I missing some debugger setting in Visual Studio to set the debug project to x64? Or is there some casting issue in the source code that produces this?
Any pointers appreciated..
The above was caused by stdrup being deprecated on Windows, and the heap becoming corrupted.
The MapServer issue on GitHub can be seen at https://github.com/mapserver/mapserver/pull/5277
This question also describes a similar issue: Heap corruption with strdup
I'm trying to run an OpenCV 2.3.1 application through Microsoft Visual C++ 2008. I have generated the release exe file correctly, and it works fine on my windows 8 - 64 bits. In addition I would like to run it on Win XP, so I have tested it on a Win XP SP3 and it ran ok. However, when I try to run this exe on Win XP SP2, which is the target O.S. for my app, I get the following message:
unable to start correctly (0xc000001d). Click Accept to finish the
application
Any idea please?
Finally I have solved the issue: 0xC000001D: Illegal instruction, which was related to the SSE instruction used in the code. Some new SSE instruction are not implemented at some different CPU; In this case, the problem was related with my CPU: "via nehemiah". I tested the software again on a XP SP2 with CPU Intel and it worked perfectly. Finally I have to say that there is a great post which was helpful in order to fix the issue:
Unhandled exception at 0x52f9e470 in project1.exe : 0xC000001D : Illegal instruction
I am using linux ubuntu , and I am using QTCreator 5.2 32 bit. I compile a program in debug mode, for debugging I use break point. when 1 compile it , it shows an assembly code and if I close assembly file and use F5 for run to next break point , it again shows assembly code,
how can I disable showing assembly mode?
Thanks
You cannot stop from showing assembly code while debugging, way out is just make sure you place break points in your code, so when you press resume button (F5 key in your case) it will come back to your code.
I have seen same behavior in Visual Studio (Windows) and XCode (Mac).
I recently developed a Visual C++ console application which uses inline SSE2 instructions. It works fine on my computer, but when I tried it on another, it returns the following error:
The system cannot execute the specified program
Note that the program worked on the other computer before introducing the SSE2 code.
Any suggestions?
PS: It works when I compile the code on the other computer and run it. I think it has something to do with the manifest from what I've scrounged off the net.
Most likely the use of the SSE2 instructions is requiring a DLL which isn't present on the second system.
Here's a blog entry on how to figure out exactly which one:
How to Debug 'The System cannot Execute the specified program' message
If you've built a debug version , a Release build might work on the other machine.
If not, you need to figure out which Microsoft Visual C++ Redistributable your program requires and install it on the other machine.