Xxxxxx.Exe Is Not a Valid Win32 Application

xxxxxx.exe is not a valid Win32 application

VS 2012 applications cannot be run under Windows XP.

See this VC++ blog on why and how to make it work.

It seems to be supported/possible from Feb 2013. See noelicus answer below on how to.

xxx.exe is not a valid Win32 application after VS just built it

  77BB8000 .data

That's almost certainly the problem, you have a very large data section. Its size is suspiciously close to what it is possible for a single executable module on Windows. You can get a more consistent repro from this sample C program:

unsigned char kaboom[0x7d000000];

int main()
{
    return 0;
}

Not a very good error message btw, Microsoft did not reserve an error code for this corner-case. And sure, it is not going to repeat that well when you are close to the edge with 0x77BB8000. The executable image must fit a single view of the memory-mapped file that the loader creates to map the code and data into memory. The view has a hard upper-limit of 2 gigabytes, fundamental for a 32-bit process and an MMF view size restriction even on the 64-bit version of Windows.

The amount of space that is available for that data section varies from one run to the next. Subtracted from the view size are the non-mappable regions at the start and the end of the address space and the space required for the operating system DLLs (at least ntdll.dll and kernel32.dll) in a 32-bit EXE process. And the space you lose due to ASLR (Address Space Layout Randomization), a number that changes. And DLLs that are injected, like those used by anti-malware and Dropbox.

It can't be guessed why your data section needs to be so large. Ask the linker to generate a .map file so you get a breakdown of the section, the large global variable ought to jump out. Be sure to target x64 so you have lots of address space available and use the free store (malloc etc) to allocate large arrays.

xx is not a valid win32 application

You need to install VS 2012 Update 1 or later or VS 2013 Express, and set your Platform Toolset to "v110_xp" or "v120_xp" to make an application that is compatible with Windows XP Service Pack 3 / Windows Server 2003 Service Pack 2).

The key difference between the "v110"/"v120" and "v110_xp"/"v120_xp" Platform Toolset is the Windows SDK. "v110"/"v120" builds with the Windows 8.x SDK which supports targeting Windows Vista or later. It is not possible to build a Windows XP compatible application using the Windows 8.x SDK. Therefore, to target Windows XP / Windows Server 2003 you have to use the alternative Platform Toolset which uses the Windows SDK 7.1A which is included with Express for Windows Desktop.

With either Windows SDK, be sure to set _WIN32_WINNT appropriately for the OSes you are targeting. See Using the Windows Headers. For Windows XP / Windows Server 2003 set it to _WIN32_WINNT=0x0501

Note that for DirectX development, this has some important impacts because the Windows 7.1 SDK was before the DirectX SDK integration that was done for the Windows 8.x SDK. See this blog post for more details.

winform, c# application, Visual Studio 2015: *.exe is not a valid Win32 application

Change the Target Framework in your project properties to 4.0. It is most likely set to 4.5.x or 4.6 which is not supported on Windows XP.

Not a valid win32 application while launching the installer

.NET 4.5 is not supported on Windows XP. There's no way to go around this. .NET 4.0 is the last version that supported Windows XP SP3. You can add many 4.5 features using NuGet packages like Microsoft.Bcl.Async for async/await support and Microsoft.Net.Http for HttpClient.

Exe is not valid win32 application but running on 64bit

You should review all the project settings.

"Win32" is just a name. For e.g., you can target Machine->X64 in linker setting despite the configuration name.

not a valid Win32 Application when building on a Windows Server 2008

I believe this is because since Go 1.13 the Windows version specified by internally-linked Windows binaries is now Windows 7:

The Windows version specified by internally-linked Windows binaries is now Windows 7 rather than NT 4.0. This was already the minimum required version for Go, but can affect the behavior of system calls that have a backwards-compatibility mode. These will now behave as documented. Externally-linked binaries (any program using cgo) have always specified a more recent Windows version.

Windows 7 has release version NT 6.1, Windows Server 2008 has release version NT 6.0 (source). So simply Windows Server 2008 does not meet the minimum required Windows version required by the built binaries.

If you need to support Windows Server 2008, try building it with Go 1.12.

---

Related Topics