| msg254349 - (view) |
Author: Laura Creighton (lac) |
Date: 2015-11-08 17:36 |
| Somebody reported this today: File "C:/Python27/kivyhello.py", line 4, in from kivy.app import App File "C:/Python27\kivy\app.py", line 316, in from kivy.base import runTouchApp, stopTouchApp File "C:/Python27\kivy\base.py", line 30, in from kivy.event import EventDispatcher File "C:/Python27\kivy\event.py", line 8, in import kivy._event ImportError: DLL load failed: %1 is not a valid Win32 application. ---------------- The problem was that they needed to set their PATH properly so kivy could be found. Couldn't we generate a more informative error message here? Is the %1 even correct? |
|
|
| msg254353 - (view) |
Author: R. David Murray (r.david.murray) *  |
Date: 2015-11-08 17:50 |
| I'm guessing that's the error we got from the OS. Maybe there's additional info we could add, though, I don't know. It would be interesting to know if it does the same thing in python3...and unfortunately it isn't as easy to change things in the python2 import system as it is in python3. |
|
|
| msg254368 - (view) |
Author: Eryk Sun (eryksun) *  |
Date: 2015-11-09 06:01 |
| The "DLL load failed" message is from Python, but the rest is the text for the Windows error code, ERROR_BAD_EXE_FORMAT (0x00c1) [1]. The "%1" in the string can be expanded as the first element of the Arguments array parameter of FormatMessage [2]. But currently the code in Python/dynload_win.c uses FORMAT_MESSAGE_IGNORE_INSERTS and does no post-processing to replace the "%1". I don't know why the Windows loader reported ERROR_BAD_EXE_FORMAT instead of ERROR_MOD_NOT_FOUND. Possibly it found another version of a dependent DLL that was corrupt or for a different architecture. Note that the setup in this case is odd in that the package is installed in C:\Python27 instead of in the site-packages directory. [1]: https://msdn.microsoft.com/en-us/library/ms681382#ERROR_BAD_EXE_FORMAT [2]: https://msdn.microsoft.com/en-us/library/ms679351 |
|
|
| msg254392 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2015-11-09 16:07 |
| OK, so it sounds like there are improvements we could make here if someone wants to work on it. |
|
|
| msg254394 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2015-11-09 16:19 |
| Does Windows provide a function to format a string using %1, %2, etc.? Note: Python 3.6 uses the same code than Python 2.7. |
|
|
| msg254395 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2015-11-09 17:12 |
| It does, but you need to identify the error code precisely and use that to provide the parameters when obtaining the message. It's more about localization than a general way of obtaining error text. Better off just using our own message in this case (which is probably a breaking change for 2.7...) |
|
|
| msg254410 - (view) |
Author: Eryk Sun (eryksun) * |
Date: 2015-11-09 21:15 |
| Steve, do you think it's OK to abandon localization for exception messages? If so, should we be using English for all FormatMessage calls? It's a bit ugly that Python's exceptions and the CRT error messages are in English, but then whenever we call FormatMessage with LANG_NEUTRAL/SUBLANG_DEFAULT we're getting localized error text. For example, the import error in the following case has a mix or Russian and English: import io, sys, ctypes kernel32 = ctypes.WinDLL('kernel32') MUI_LANGUAGE_NAME = 8 kernel32.SetThreadPreferredUILanguages(MUI_LANGUAGE_NAME, u'ru-RU\0', None) kernel32.SetConsoleOutputCP(1251) sys.stderr = io.TextIOWrapper(open(r'\\.\con', 'wb'), encoding='1251') open('blah.pyd', 'w').close() >>> import blah Traceback (most recent call last): File "", line 1, in ImportError: DLL load failed: %1 не является приложением Win32. |
|
|
| msg254430 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2015-11-10 04:29 |
| For 3.6 I think it's fine, but people are almost certainly relying on the current message on their system and changing it at all for any existing release is unnecessary pain (3.5.1 *might* be okay, but only because it's so recent). It would be nice to invest in some better diagnostics here, though with the ABI tag in 3.5 you're now unlikely to get an incompatible binary. File not found will be the most common message. |
|
|
| msg254431 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2015-11-10 04:30 |
| Correction, *import* not found, and the only way to resolve it is to do a second scan of sys.path for the sole purpose of diagnostics. Probably more harmful than helpful. |
|
|
| msg261352 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2016-03-08 11:56 |
| See also issue #26493. |
|
|
| msg387655 - (view) |
Author: Eryk Sun (eryksun) * |
Date: 2021-02-25 09:21 |
| In 3.8+, the DLL search path for dependent DLLs when importing extension modules excludes PATH and the current working directory. So it's far less likely for an import to fail with ERROR_BAD_EXE_FORMAT. Currently the error message in Python 3 includes the base name of the extension module, e.g. "DLL load failed while importing _spam". No error codes are special cased to use custom error messages, so it still includes the localized error text from the system, which may contain parameterized inserts (%). The common errors when importing an extension module are missing and mismatched dependent DLLs: ERROR_MOD_NOT_FOUND (126) and ERROR_PROC_NOT_FOUND (127). The system messages for these two errors do not contain inserts. For example, if the UI language is Japanese, a missing DLL dependency raises the following exception: ImportError: DLL load failed while importing _spam: 指定されたモジュールが見つかりません。 |
|
|