Why is %1 rarely substituted in "%1 is not a valid Win32 application."

6
votes

I'm sure most Windows developers are familiar with this error message, usually when trying to mix 32- and 64-bit executables. In particular Python and Java can both get it.

%1 is not a valid Win32 application.

It's clear that %1 represents the first argument to the failing command - i.e. the executable that is trying to be loaded - but why does it not get filled in with the actual path?

Is it something that the caller is doing wrong, or is it a basic failing of some Windows subsystem that cannot be fixed for compatibility reasons?

2
windowswinapidll32bit-64bitcreateprocess
Do you have a specific situation you can point us to that generates the error? I can't say that I've ever seen it. – Mark Ransom
Take a look at the "Related" list or just search SO for it -> – OrangeDog
@MarkRansom the two I've been recently annoyed by involve loading a native Python module that was built with the wrong architecture, and an Apache project installing itself with 32-bit commons-daemon on a 64-bit JVM. – OrangeDog

2 Answers

8
votes

The error message comes from Windows itself, you can see the complete list at System Error Codes (0-499). You translate an error code returned by the API into a message using FormatMessage, which has an optional Arguments array; any %1 in the message will be replaced by the first element in this array. If nothing is passed for the arguments, the %1 will be left unchanged if the FORMAT_MESSAGE_IGNORE_INSERTS flag was used or the FormatMessage will fail if it wasn't (thanks to IInspectable for that information).

As an example of how this might get missed, consider code where an error code gets converted immediately to an exception. If the exception contains the error code but nothing else, then there is no context for knowing what to pass to FormatMessage.

6
votes

The caller is doing everything right. They are calling FormatMessage, passing along the FORMAT_MESSAGE_IGNORE_INSERTS flag1), like everyone should. The caller is not in control of the message that gets created, and has no way of knowing, that it should pass additional arguments, what types they should be or how many.

This was an early design bug in the Windows error reporting system, and you'll see those placeholders in every well-behaved application.

1)See The importance of the FORMAT_MESSAGE_IGNORE_INSERTS flag.