Standalone executable on Windows fails with Runtime Error R6034 - pyInstaller-1.5-rc1

[Stefan Fruehwirth]

Hi,

when running a standalone executable using arbitrary code like this
line:

---
print "confusing cat..."
---

I get a dialog box "Microsoft Visual C++ Runtime Library" with the
following text content:

---
Runtime Error!
Program: [path-to-program]
R6034
An application has made an attempt to load the C runtime library
incorrectly.
Please contact the application's support team for more information.
---

The code execution resumes, output is correct. However, I tried to
narrow it down and found out that the error disappears when I put a
"progName.exe.manifest" file with following content in the same
directory:

---
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-
com:asm.v1">
<assemblyIdentity name="progName" processorArchitecture="x86"
type="win32" version="1.0.0.0"/>
<dependency>
<dependentAssembly>
<assemblyIdentity name="Microsoft.VC90.CRT"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"
type="win32" version="9.0.21022.8"/>
</dependentAssembly>
</dependency>
</assembly>
---

Any Ideas? Bug? Send to trac?

Thanks,
Stefan

[Giovanni Bajo]

Obviously this works for most people, so it has to be something specific
to your system. Nonetheless, it's still a bug that we need some help to
sort out.

Does it work in one-dir mode? And in one-file mode? What Python version
are you using? What operating system are you running on?

Can you please send:

* The full output of Build.py
* A list of all files bundled in one-dir mode

Thanks!
--
Giovanni Bajo :: ra...@develer.com
Develer S.r.l. :: http://www.develer.com

My Blog: http://giovanni.bajo.it
Last post: Compile-time Function Execution in D

[Florian Höch]

Hi,

Am 10.01.2011 12:30, schrieb Stefan Fruehwirth:
> Hi,
>
> when running a standalone executable using arbitrary code like this
> line:
>
> ---
> print "confusing cat..."
> ---
>
> I get a dialog box "Microsoft Visual C++ Runtime Library" with the
> following text content:
>
> ---
> Runtime Error!
> Program: [path-to-program]
> R6034
> An application has made an attempt to load the C runtime library
> incorrectly.
> Please contact the application's support team for more information.
> ---

This problem has been reported before, unfortunately, the cause is still
somewhat in the dark.

>
> The code execution resumes, output is correct. However, I tried to
> narrow it down and found out that the error disappears when I put a
> "progName.exe.manifest" file with following content in the same
> directory:

Interesting. Normally, this file should be generated automatically by
pyinstaller (in --onedir mode, it should land in the output folder along
with the exe, in --onefile mode, it should be part of the archive
embedded in the final executable, which can be checked with
pyinstaller's ArchiveViewer.py).

Regards
--
Florian Höch

[Florian Höch]

Hi Giovanni,

I noticed that the bootloader executables contain a manifest as resource
since some time (I don't know since when, but some of my older exe's do
not contain it). While this doesn't lead to problems on my setup, it may
be related to the R6034 error reported by others. Can we get rid of the
manifest in the bootloader? The only contents seem to be security
options for Vista/Win7, which I could add to the manifest generated by
pyinstaller (I already added it to my local build, it was a trivial
change, but I didn't commit yet).

Regards

--
Florian Höch

[Giovanni Bajo]

On Mon, 2011-01-10 at 21:26 +0100, Florian Höch wrote:
> Hi Giovanni,
>
> I noticed that the bootloader executables contain a manifest as resource
> since some time (I don't know since when, but some of my older exe's do
> not contain it).

Hi Florian,

there is a 0-byte manifest.xml in source/windows; I messed up with it,
it should have been removed after your patch (after the manifest is
generated by Build.py).

As for the embedded manifest in the executables, I don't know how it
gets there... can you please have a look?

> While this doesn't lead to problems on my setup, it may
> be related to the R6034 error reported by others. Can we get rid of the
> manifest in the bootloader? The only contents seem to be security
> options for Vista/Win7, which I could add to the manifest generated by
> pyinstaller (I already added it to my local build, it was a trivial
> change, but I didn't commit yet).

Yes, we can get rid of it, I don't think it should be generated in the
first place, and I don't know if it's useful or not. So, rather than
regenerating it from your patch, can you please check how it gets added
to the executable?

Maybe through the new build system? Martin?

[Martin Zibricky]

Giovanni Bajo píše v Út 11. 01. 2011 v 11:30 +0100:

> As for the embedded manifest in the executables, I don't know how it
> gets there... can you please have a look?
>
> > While this doesn't lead to problems on my setup, it may
> > be related to the R6034 error reported by others. Can we get rid of
> the
> > manifest in the bootloader? The only contents seem to be security
> > options for Vista/Win7, which I could add to the manifest generated
> by
> > pyinstaller (I already added it to my local build, it was a trivial
> > change, but I didn't commit yet).
>
> Yes, we can get rid of it, I don't think it should be generated in the
> first place, and I don't know if it's useful or not. So, rather than
> regenerating it from your patch, can you please check how it gets
> added
> to the executable?
>
> Maybe through the new build system? Martin?

The maanifest seems really getting there through the new build system.
When using visual studio compiler, the manifest is always generated.

Giovanni, could you please verify if MSVC 2003 uses lingflag /MANIFEST
during compilation?

You could get compilation details with using waf option -vv:

python waf -vv build

Part of waf code where manifest is handled:
http://code.google.com/p/waf/source/browse/tags/waf-1.5.18/wafadmin/Tools/msvc.py?r=10833

Maybe other useful information:
http://code.google.com/p/waf/issues/detail?id=595

Should I try to change the new build system to not embed manifest to
bootloader?

[Giovanni Bajo]

On Tue, 2011-01-11 at 14:01 +0100, Martin Zibricky wrote:
> Giovanni Bajo píše v Út 11. 01. 2011 v 11:30 +0100:
> > As for the embedded manifest in the executables, I don't know how it
> > gets there... can you please have a look?
> >
> > > While this doesn't lead to problems on my setup, it may
> > > be related to the R6034 error reported by others. Can we get rid of
> > the
> > > manifest in the bootloader? The only contents seem to be security
> > > options for Vista/Win7, which I could add to the manifest generated
> > by
> > > pyinstaller (I already added it to my local build, it was a trivial
> > > change, but I didn't commit yet).
> >
> > Yes, we can get rid of it, I don't think it should be generated in the
> > first place, and I don't know if it's useful or not. So, rather than
> > regenerating it from your patch, can you please check how it gets
> > added
> > to the executable?
> >
> > Maybe through the new build system? Martin?
>
> The maanifest seems really getting there through the new build system.
> When using visual studio compiler, the manifest is always generated.
>
> Giovanni, could you please verify if MSVC 2003 uses lingflag /MANIFEST
> during compilation?
>
> You could get compilation details with using waf option -vv:
>
> python waf -vv build

I will check, but I was trying to use VS2008 to build the bootloader,
given the availability of the free-as-in-beer express version.

> Part of waf code where manifest is handled:
> http://code.google.com/p/waf/source/browse/tags/waf-1.5.18/wafadmin/Tools/msvc.py?r=10833
>
> Maybe other useful information:
> http://code.google.com/p/waf/issues/detail?id=595
>
> Should I try to change the new build system to not embed manifest to
> bootloader?

Yes please. It would be great if you could hack something "dirty and
quick" so that we can at least check if it's related to the R6034 issue
that people are experimenting. After this check, we can decide what's
the best way forward to implement a clean solution.

Thanks!

[Stefan Fruehwirth]

On 10 Jan., 20:19, Giovanni Bajo <ra...@develer.com> wrote:

> Does it work in one-dir mode? And in one-file mode? What Python version
> are you using? What operating system are you running on?

The problem occurs only in one-file mode, that's why I took the
manifest from the one-dir output and put it in the output dir of one-
file mode.
I'm using WinXP SP3 and Python 2.6.5

> Can you please send:
>
>  * The full output of Build.py

I: Analyzing C:\Python26\python.exe
I: Dependent assemblies of C:\Python26\python.exe:
I: x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww
Adding Microsoft.VC90.CRT to dependent assemblies of final executable
I: Searching for assembly
x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww...
I: Found manifest C:\WINDOWS\WinSxS\Manifests
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375.manifest
I: Searching for file msvcr90.dll
I: Found file C:\WINDOWS\WinSxS
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375\msvcr90.dll
I: Searching for file msvcp90.dll
I: Found file C:\WINDOWS\WinSxS
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375\msvcp90.dll
I: Searching for file msvcm90.dll
I: Found file C:\WINDOWS\WinSxS
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375\msvcm90.dll
I: Adding Microsoft.VC90.CRT.manifest
I: Adding msvcr90.dll
I: Adding msvcp90.dll
I: Adding msvcm90.dll
I: Adding python26.dll dependency of python.exe
I: Skipping KERNEL32.dll dependency of python.exe
I: Analyzing C:\WINDOWS\system32\python26.dll
I: Dependent assemblies of C:\WINDOWS\system32\python26.dll:
I: x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww
I: Skipping KERNEL32.dll dependency of python26.dll
I: Skipping USER32.dll dependency of python26.dll
I: Skipping ADVAPI32.dll dependency of python26.dll
I: Skipping SHELL32.dll dependency of python26.dll
I: Analyzing C:\Python26\DLLs\_ctypes.pyd
I: Skipping KERNEL32.dll dependency of _ctypes.pyd
I: Skipping ole32.dll dependency of _ctypes.pyd
I: Skipping OLEAUT32.dll dependency of _ctypes.pyd
I: Analyzing C:\Python26\DLLs\select.pyd
I: Skipping WSOCK32.dll dependency of select.pyd
I: Skipping KERNEL32.dll dependency of select.pyd
I: Analyzing C:\Python26\DLLs\unicodedata.pyd
I: Skipping KERNEL32.dll dependency of unicodedata.pyd
I: Analyzing C:\Python26\DLLs\bz2.pyd
I: Skipping KERNEL32.dll dependency of bz2.pyd
I: Analyzing C:\Python26\DLLs\_ssl.pyd
I: Skipping WS2_32.dll dependency of _ssl.pyd
I: Skipping KERNEL32.dll dependency of _ssl.pyd
I: Skipping USER32.dll dependency of _ssl.pyd
I: Skipping GDI32.dll dependency of _ssl.pyd
I: Skipping ADVAPI32.dll dependency of _ssl.pyd
I: Analyzing C:\Python26\lib\site-packages\win32\win32api.pyd
I: Skipping USER32.dll dependency of win32api.pyd
I: Skipping ADVAPI32.dll dependency of win32api.pyd
I: Skipping SHELL32.dll dependency of win32api.pyd
I: Skipping VERSION.dll dependency of win32api.pyd
I: Skipping POWRPROF.dll dependency of win32api.pyd
I: Adding pywintypes26.dll dependency of win32api.pyd
I: Skipping KERNEL32.dll dependency of win32api.pyd
I: Analyzing C:\Python26\DLLs\_socket.pyd
I: Skipping WS2_32.dll dependency of _socket.pyd
I: Skipping KERNEL32.dll dependency of _socket.pyd
I: Analyzing C:\WINDOWS\system32\pywintypes26.dll
I: Skipping ADVAPI32.dll dependency of pywintypes26.dll
I: Skipping USER32.dll dependency of pywintypes26.dll
I: Skipping ole32.dll dependency of pywintypes26.dll
I: Skipping OLEAUT32.dll dependency of pywintypes26.dll
I: Skipping KERNEL32.dll dependency of pywintypes26.dll
Warnings written to .\pyInstallerR6034Issue
\warnpyInstallerR6034Issue.txt
checking PYZ
rebuilding outPYZ1.toc because outPYZ1.pyz is missing
building PYZ outPYZ1.toc
checking PKG
rebuilding outPKG3.toc because outPKG3.pkg is missing
building PKG outPKG3.pkg
checking EXE
rebuilding outEXE2.toc because pyInstallerR6034Issue.exe missing
building EXE from outEXE2.toc
Appending archive to EXE .\pyInstallerR6034Issue\build
\pyi.win32\pyInstallerR6034Issue\pyInstallerR6034Issue.exe
checking COLLECT
building because outCOLLECT4.toc missing or bad
building COLLECT outCOLLECT4.toc

>  * A list of all files bundled in one-dir mode

bz2.pyd
Microsoft.VC90.CRT.manifest
msvcm90.dll
msvcp90.dll
msvcr90.dll
pyInstallerR6034Issue.exe
pyInstallerR6034Issue.exe.manifest
python26.dll
pywintypes26.dll
select.pyd
unicodedata.pyd
win32api.pyd
_ctypes.pyd
_socket.pyd
_ssl.pyd

Thanks,
Stefan

[Florian Höch]

The --onefile Build.py log looks fine I think, also the --onedir contents.
Can you run
pyinstaller\ArchiveViewer.py <path-to-your-onefile-executable>
and post the list of files?

Regards
--
Florian Höch

[Stefan Fruehwirth]

On 11 Jan., 15:30, Florian Höch <florian.ho...@gmx.de> wrote:

> The --onefile Build.py log looks fine I think, also the --onedir contents.
> Can you run
> pyinstaller\ArchiveViewer.py <path-to-your-onefile-executable>
> and post the list of files?

Output:

pos, length, uncompressed, iscompressed, type, name
[(0, 681871, 681871, 0, 'z', 'outPYZ1.pyz'),
(681871, 8342, 24121, 1, 'm', 'iu'),
(690213, 169, 234, 1, 'm', 'struct'),
(690382, 6010, 16552, 1, 'm', 'archive'),
(696392, 1157, 2272, 1, 's', '_mountzlib'),
(697549, 81, 76, 1, 's', 'useUnicode'),
(697630, 34, 26, 1, 's', 'pyInstallerR6034Issue'),
(697664, 39920, 87552, 1, 'b', '_ctypes.pyd'),
(737584, 5444, 10240, 1, 'b', 'select.pyd'),
(743028, 231896, 583680, 1, 'b', 'unicodedata.pyd'),
(974924, 35130, 69632, 1, 'b', 'bz2.pyd'),
(1010054, 391031, 805376, 1, 'b', '_ssl.pyd'),
(1401085, 38022, 95744, 1, 'b', 'win32api.pyd'),
(1439107, 20385, 43008, 1, 'b', '_socket.pyd'),
(1459492, 602, 1857, 1, 'b', 'Microsoft.VC90.CRT.manifest'),
(1460094, 317595, 655872, 1, 'b', 'msvcr90.dll'),
(1777689, 155722, 568832, 1, 'b', 'msvcp90.dll'),
(1933411, 66835, 224768, 1, 'b', 'msvcm90.dll'),
(2000246, 1049758, 2262528, 1, 'b', 'python26.dll'),
(3050004, 42514, 109568, 1, 'b', 'pywintypes26.dll'),
(3092518, 274, 488, 1, 'b', 'pyInstallerR6034Issue.exe.manifest')]

The manifest file seems to be included, the content is the same as in
onedir mode.

Stefan

[Giovanni Bajo]

Another test: change your program so that it prints
os.environ["_MEIPASS2"] and doesn't exit immediately; then, while it is
running, go to the temporary directory that was printed and check if the
manifest file is there.

[Stefan Fruehwirth]

On 11 Jan., 16:53, Giovanni Bajo <ra...@develer.com> wrote:

> Another test: change your program so that it prints
> os.environ["_MEIPASS2"] and doesn't exit immediately; then, while it is
> running, go to the temporary directory that was printed and check if the
> manifest file is there.

Yep, same content. Strange. I'm starting to think that my system is
messed up. Although I have experienced no troubles elswhere :-/

Stefan

[Florian Höch]

Hmm, maybe, but I somehow doubt it :) My bets are currently on getting
rid of the redundant manifest resource in the bootloader, hoping that
this will already be enough to eventually fix the problem (it could be a
race condition between WinSxS automatically grabbing the manifest
resource, thus somehow blocking pyinstaller's own attempt at loading the
correct manifest. But that's really just my speculation at the moment).

Regards
--
Florian Höch

[Giovanni Bajo]

I've just committed an updated bootloader in SVN trunk (thanks to Martin
for disabling manifest generation), for Windows 32-bit.

Stefan, can you please try again with SVN trunk? (assuming you are not
using 64-bit Python on 64-bit Windows)
--
Giovanni Bajo :: Develer S.r.l.
ra...@develer.com :: http://www.develer.com

[Martin Zibricky]

Giovanni Bajo píše v St 12. 01. 2011 v 00:25 +0100:

> I've just committed an updated bootloader in SVN trunk (thanks to
> Martin
> for disabling manifest generation), for Windows 32-bit.
>
> Stefan, can you please try again with SVN trunk? (assuming you are not
> using 64-bit Python on 64-bit Windows)

What I did was that when compiling bootloader the manifest file is not
embedded to executable by manifest tool 'mt.exe'.

However there is still passed link flag '/MANIFEST' to the compiler. So
if it still won't work we could try something with this flag (disable,
etc.).

This is explanation of this flag:
http://msdn.microsoft.com/en-us/library/f2c0w594(v=vs.80).aspx

Martin

[Giovanni Bajo]

I don't think it matters: that flag just asks the linker to create the
manifest on the disk. Since we don't copy it over from the build
directory, nor embed it anymore with mt.exe, it does not affect the
generated executable, as far as I can tell.

--
Giovanni Bajo :: ra...@develer.com
Develer S.r.l. :: http://www.develer.com

My Blog: http://giovanni.bajo.it

[Stefan Fruehwirth]

On 12 Jan., 00:25, Giovanni Bajo <ra...@develer.com> wrote:

> Stefan, can you please try again with SVN trunk? (assuming you are not
> using 64-bit Python on 64-bit Windows)

Tried it, I'm not using any 64-bit versions. The error is still there
in svn trunk rev. 1305, the manifest file in the temp location is
missing.

Thanks,
Stefan

[Florian Höch]

Just to be sure, is the manifest missing in the temp location a new
problem? Is the manifest still present in the executable archive?

(I thought from your last answer to Giovanni that the manifest was
actually extracted succesfully then)

Regards
--
Florian Höch

[Giovanni Bajo]

Just to make sure: did you unpack PyInstaller in a different directory
(no reuse of internal bincache directories) and did you rebuild the
application from scratch (no reuse of build temporaries)?

--
Giovanni Bajo :: ra...@develer.com
Develer S.r.l. :: http://www.develer.com

My Blog: http://giovanni.bajo.it

[Stefan Fruehwirth]

On 13 Jan., 19:45, Giovanni Bajo <ra...@develer.com> wrote:

> Just to make sure: did you unpack PyInstaller in a different directory
> (no reuse of internal bincache directories) and did you rebuild the
> application from scratch (no reuse of build temporaries)?

Oops, sorry. I must have missed it the first time, the manifest exists
in the temp dir - so nothing has changed here as I can tell.
Unfortunately the error persists too.

I did a completely new configuration/makespec/build with the svn trunk
version in a separate directory - the two versions are completely
separated.

Stefan

[Giovanni Bajo]

Can you please build in debug mode (debug=1 in the spec) and console
(console=1 in the spec), then run the program from the command line and
tell me the output on the console before the message box appears, and
after.

[Stefan Fruehwirth]

On 14 Jan., 15:02, Giovanni Bajo <ra...@develer.com> wrote:

> Can you please build in debug mode (debug=1 in the spec) and console
> (console=1 in the spec), then run the program from the command line and
> tell me the output on the console before the message box appears, and
> after.

Before:

_MEIPASS2 is NULL
Extracting binaries
Executing self as child with Setting up to run child
Creating child process
Waiting for child process to finish...
_MEIPASS2 is C:/path-to-user-dir/Temp/_MEI41322/
Already in the child - running!
manifestpath: C:/path-to-user-dir/Temp/_MEI41322/
pyInstallerR6034Issue.exe.manifest
Activation context created
Activation context activated
C:/path-to-user-dir/Temp/_MEI41322/python26.dll
Manipulating evironment
PYTHONPATH=C:/path-to-user-dir/Temp/_MEI41322;C:/pyinstaller-svn-trunk-
r1305/pyInstallerR6034Issue/dist
importing modules from CArchive
extracted iu
extracted struct
extracted archive
Installing import hooks
outPYZ1.pyz
Running scripts

After:

confusing cat...
C:/path-to-user-dir/Temp/_MEI41322/

Stefan

[Martin Zibricky]

Stefan Fruehwirth píše v Po 10. 01. 2011 v 03:30 -0800:

>
> Hi,
>
> when running a standalone executable using arbitrary code like this
> line:
>
> ---
> print "confusing cat..."
> ---
>
> I get a dialog box "Microsoft Visual C++ Runtime Library" with the
> following text content:

Is anybody able to reproduce it? I will try that.

[Martin Zibricky]

Stefan Fruehwirth píše v Pá 14. 01. 2011 v 08:03 -0800:

>
> On 14 Jan., 15:02, Giovanni Bajo <ra...@develer.com> wrote:
>
> > Can you please build in debug mode (debug=1 in the spec) and console
> > (console=1 in the spec), then run the program from the command line
> and
> > tell me the output on the console before the message box appears,
> and
> > after.

I'm trying to reproduce this issue on my winxp sp3 En with python 2.6.5.
I'm not able to reproduce that yet. PyInstaller works in both modes
(onedir and onefile).

I think there must be something unusual in your system. Can you think of
anything?

What is the output of your %PATH% variable? command:

echo %PATH%

And what is the real value of 'path-to-user-dir' from your debug output?
Or just if it does not contain any localization characters.

Regards Martin

[Martin Zibricky]

How could one know what name of the manifest file will the executable
use?

When the bootloader is compiled with the link flag '/MANIFEST', the name
of the executables are:

run.exe
runw.exe
run_d.exe
runw_d.exe

So the manifest file should be in this case:

run.exe.manifest
runw.exe.manifest
run_d.exe.manifest
runw_d.exe.manifest

However. when a python app is frozen and the exe file renamed is it
supposed that the file name of the manifest will be
new_app_name.exe.manifest?

Stefan or anybody else having this error could try rename the manifest
file to anything from the following, if it will work:

run.exe.manifest
runw.exe.manifest
run_d.exe.manifest
runw_d.exe.manifest

This is just an idea what else to try. Is really anybody able to
successfully reproduce this error?

[Giovanni Bajo]

On Wed, 2011-01-19 at 14:59 +0100, Martin Zibricky wrote:
> How could one know what name of the manifest file will the executable
> use?

The bootloader does the equivalent of sys.argv[0]+".manifest". Since it
dynamically loads the manifest, it works unless the end user renames the
executable (which is never supported by PyInstaller, eg. it breaks the
multi-package mode).

[Martin Zibricky]

Giovanni Bajo píše v St 19. 01. 2011 v 15:07 +0100:

> The bootloader does the equivalent of sys.argv[0]+".manifest". Since
> it
> dynamically loads the manifest, it works unless the end user renames
> the
> executable (which is never supported by PyInstaller, eg. it breaks the
> multi-package mode).

What makes me worried is the following text from

http://msdn.microsoft.com/en-us/library/f2c0w594(v=vs.80).aspx

----
If you specify /MANIFEST, the name of the manifest file will be the same
as the name of your output file, with .manifest appended to the file
name. For example, if your output file name is MyFile.exe, the manifest
file name will be MyFile.exe.manifest. If you
specify /MANIFESTFILE:name, the name of the manifest will be what you
specify in name.
----

So I think that when using the linkflag '/MANIFEST' the name of the
required manifest file is hard coded in the executable to values like
'run.exe.manifest' and that loading manifest file dynamically is then
overriden.

Let's try to compile bootloaders also without the linkflag /MANIFEST if
and we'll see if it could help.

[Giovanni Bajo]

I think you're mixmatching the issues.

/MANIFEST only generates the manifest on the disk. If you remove that
flag from the linker command line, the manifest is simply not
generated. /MANIFEST does not modify the executable in any form.

For a manifest to be automatically loaded and activated by the operating
system, there are two ways:

* Either the manifest is on the disk, next to the executable, with the
same name of the executable plus ".manifest"
* or the manifest is embedded within the executable (embedding is
usually achieved through the mt.exe tool after linking).

In the case of PyInstaller, we load and activate the manifest "manually"
through Win32 APIs in one-file mode (since it's extracted to the temp
directory); in one-dire mode, the OS loads it automatically since it
sits there on the disk next to the executable.

[Stefan Fruehwirth]

On 19 Jan., 14:59, Martin Zibricky <mzibri...@gmail.com> wrote:

> I think there must be something unusual in your system. Can you think of
> anything?

No, but I already had the suspicion that there is something wrong with
the system. My worry is that it may be occuring on some other systems
too and that's exactly the thing I'm trying to prevent. The whole
point of the installer is (for me in this case) that I can distribute
a script to various systems without python installed.

Besides that I'm not a real Win$ enthusiast and therefore not able to
provide knowledge of the library loading process.

> What is the output of your %PATH% variable? command:

C:\Python26\Scripts;C:\Python26\;c:\gtk\bin;C:\WINDOWS\system32;C:
\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\NTRU C
ryptosystems\NTRU TCG Software Stack\bin\;C:\Programme\Wave Systems
Corp\Gemalto\Access Client\v5\;C:\Programme\Intel\D
MIX;C:\Programme\Gemeinsame Dateien\Roxio Shared\DLLShared\;C:
\Programme\Gemeinsame Dateien\Roxio Shared\9.0\DLLShared\
;C:\Programme\QuickTime\QTSystem\;C:\Programme\Intel\WiFi\bin\;C:
\WINDOWS\system32\WindowsPowerShell\v1.0\;C:\Programme
\TortoiseSVN\bin;%APPDATA%\Python\Scripts

> And what is the real value of 'path-to-user-dir' from your debug output?
> Or just if it does not contain any localization characters.

C:/DOKUME~1/fruehwir/LOKALE~1/ (localized german layout)

> Stefan or anybody else having this error could try rename the manifest
> file to anything from the following, if it will work:
>
> run.exe.manifest
> runw.exe.manifest
> run_d.exe.manifest
> runw_d.exe.manifest

I'm afraid I don't understand what you mean. When the manifest file is
already there in onefile mode there is no problem. The error comes up
when the manifest file is missing. So what would changing the name
show? If you mean changing the manifest in the config of the build
process then I have to pass because I'm neither familiar with the
internals of pyInstaller nor the library loading stuff of Windows XP.

Stefan

[Martin Zibricky]

Stefan Fruehwirth píše v Čt 20. 01. 2011 v 04:02 -0800:

> The error comes up
> when the manifest file is missing. So what would changing the name
> show? If you mean changing the manifest in the config of the build
> process then I have to pass because I'm neither familiar with the
> internals of pyInstaller nor the library loading stuff of Windows XP.

So is the problem that in onefile mode the manifest is missing and this
causes the Runtime Error R6034 and so we need to find out why the
manifest is missing and fix it?

Could you pleases summarize the symptoms in onefile/onedir mode and what
you tried, what helped and what not?

Could you please publish somewhere the exe of your test example so I
could try that if it's failing for me?

Thanks in advance.

Martin

[Martin Zibricky]

Stefan Fruehwirth píše v Čt 20. 01. 2011 v 04:02 -0800:

> > And what is the real value of 'path-to-user-dir' from your debug
> output?
> > Or just if it does not contain any localization characters.
>
> C:/DOKUME~1/fruehwir/LOKALE~1/ (localized german layout)

So do you use as username this string 'früwirt'?

[Stefan Fruehwirth]

On 20 Jan., 13:24, Martin Zibricky <mzibri...@gmail.com> wrote:

> Could you pleases summarize the symptoms in onefile/onedir mode and what
> you tried, what helped and what not?

The symptoms didn't change since my initial post - so please use this
information.

> Could you please publish somewhere the exe of your test example so I
> could try that if it's failing for me?

http://ling.uni-graz.at/~fruehwir/pyInstallerR6034Issue.exe

In the meantime I tried it on another machine, same behavior. My
username is "fruehwir" by the way :) - exaclty as noted in the
directory. Although I don't know how this could be relevant.

Stefan

[Florian Höch]

> http://ling.uni-graz.at/~fruehwir/pyInstallerR6034Issue.exe

Something very strange (imho) is happening when I try and launch this
executable on my Win7 64 system (only sys I tried to run it on so far):

I get an UAC dialog ("Do you want to allow the following program from an
unknown publisher to make changes to this computer?"). Very unusual, has
never happened to me (with pyinstaller).

If I click OK in that dialog, I get the console window with the first
part of the debug output, then the R6034 error. After I click OK in the
error dialog, the second half of the output is displayed; after I close
the executable by hitting the return key, I get a Windows dialog "This
program might not have installed correctly" with the usual choices
"Reinstall using recommended settings" or "This program was installed
correctly".

Honestly, I have not the slightest idea what is going on there :)

Can anyone reproduce the behavior I described? (I should note that I
have UAC on the highest setting, but even returning it to the default
showed the same results)

Regards
--
Florian Höch

[Giovanni Bajo]

On Thu, 2011-01-20 at 15:47 +0100, Florian Höch wrote:
> > http://ling.uni-graz.at/~fruehwir/pyInstallerR6034Issue.exe
>
> Something very strange (imho) is happening when I try and launch this
> executable on my Win7 64 system (only sys I tried to run it on so far):

Can you please compare the differences between this binary and the same
binary packaged by PyInstaller on your own computer? Since the program
itself is a one-liner, and you can install the very same version of
Python, it should be possible to compare the binary file by file and see
where the difference lies.

[Florian Höch]

Ok, atleast the "mystery" of the UAC prompt is resolved. Windows 7
simply shows it if it finds "Installer" or "Setup" in the filename, I
renamed the file to something else and no UAC prompt is shown. So I
think that was just a red herring.

I downgraded to Python 2.6.5 and built an executable.

Comparing the contents of the two exe's using ArchiveViewer.py:

pyInstallerR6034Issue.exe (mine)

pos, length, uncompressed, iscompressed, type, name

[(0, 567033, 567033, 0, 'z', 'outPYZ1.pyz'),
(567033, 8308, 22705, 1, 'm', 'iu'),
(575341, 169, 234, 1, 'm', 'struct'),
(575510, 5988, 15712, 1, 'm', 'archive'),
(581498, 1157, 2272, 1, 's', '_mountzlib'),
(582655, 81, 76, 1, 's', 'useUnicode'),
(582736, 84, 81, 1, 's', 'pyInstallerR6034Issue'),
(582820, 38275, 96256, 1, 'b', 'win32api.pyd'),
(621095, 6011, 11776, 1, 'b', 'select.pyd'),
(627106, 233097, 585728, 1, 'b', 'unicodedata.pyd'),
(860203, 36925, 71680, 1, 'b', 'bz2.pyd'),
(897128, 602, 1857, 1, 'b', 'Microsoft.VC90.CRT.manifest'),
(897730, 317595, 655872, 1, 'b', 'msvcr90.dll'),
(1215325, 155722, 568832, 1, 'b', 'msvcp90.dll'),
(1371047, 66835, 224768, 1, 'b', 'msvcm90.dll'),
(1437882, 1054327, 2145280, 1, 'b', 'python26.dll'),
(2492209, 42972, 110592, 1, 'b', 'pywintypes26.dll'),
(2535181, 274, 488, 1, 'b', 'pyInstallerR6034Issue.exe.manifest')]

http://ling.uni-graz.at/~fruehwir/pyInstallerR6034Issue.exe

pos, length, uncompressed, iscompressed, type, name
[(0, 681871, 681871, 0, 'z', 'outPYZ1.pyz'),

(681871, 8361, 24593, 1, 'm', 'iu'),
(690232, 169, 234, 1, 'm', 'struct'),
(690401, 6022, 16832, 1, 'm', 'archive'),
(696423, 1157, 2272, 1, 's', '_mountzlib'),
(697580, 81, 76, 1, 's', 'useUnicode'),
(697661, 108, 111, 1, 's', 'pyInstallerR6034Issue'),
(697769, 39920, 87552, 1, 'b', '_ctypes.pyd'),
(737689, 5444, 10240, 1, 'b', 'select.pyd'),
(743133, 231896, 583680, 1, 'b', 'unicodedata.pyd'),
(975029, 35130, 69632, 1, 'b', 'bz2.pyd'),
(1010159, 391031, 805376, 1, 'b', '_ssl.pyd'),
(1401190, 38022, 95744, 1, 'b', 'win32api.pyd'),
(1439212, 20385, 43008, 1, 'b', '_socket.pyd'),
(1459597, 602, 1857, 1, 'b', 'Microsoft.VC90.CRT.manifest'),
(1460199, 317595, 655872, 1, 'b', 'msvcr90.dll'),
(1777794, 155722, 568832, 1, 'b', 'msvcp90.dll'),
(1933516, 66835, 224768, 1, 'b', 'msvcm90.dll'),
(2000351, 1049758, 2262528, 1, 'b', 'python26.dll'),
(3050109, 42514, 109568, 1, 'b', 'pywintypes26.dll'),
(3092623, 274, 488, 1, 'b', 'pyInstallerR6034Issue.exe.manifest')]

So looking at the file sizes there are numerous differences, also some
extras, _ctypes.pyd, _socket.pyd and _ssl.pyd. I'm using python.org
Python, maybe the other is ActiveState?

Am 20.01.2011 19:38, schrieb Giovanni Bajo:
> On Thu, 2011-01-20 at 15:47 +0100, Florian Höch wrote:
>>> http://ling.uni-graz.at/~fruehwir/pyInstallerR6034Issue.exe
>>
>> Something very strange (imho) is happening when I try and launch this
>> executable on my Win7 64 system (only sys I tried to run it on so far):
>
> Can you please compare the differences between this binary and the same
> binary packaged by PyInstaller on your own computer? Since the program
> itself is a one-liner, and you can install the very same version of
> Python, it should be possible to compare the binary file by file and see
> where the difference lies.

--
Florian Höch

[Martin Zibricky]

Florian Höch píše v Čt 20. 01. 2011 v 21:59 +0100:

> So looking at the file sizes there are numerous differences, also
> some
> extras, _ctypes.pyd, _socket.pyd and _ssl.pyd. I'm using python.org
> Python, maybe the other is ActiveState?

Hi Stefan, do you use python installer from www.python.org or from
http://www.activestate.com/?

[Stefan Fruehwirth]

On 20 Jan., 23:44, Martin Zibricky <mzibri...@gmail.com> wrote:

> Hi Stefan, do you use python installer fromwww.python.orgor fromhttp://www.activestate.com/?

Damn! I'm so sorry! I forgot to check where the python entry in my
$PATH points to - it is ActiveState. I don't remeber why I installed
it on this machine. As I'm usually using 2.5 I didn't pay much
attention to this and only checked the version with python --version.

I'll try it with python.org later, and let you know whether it works.

Sorry for wasting your time, I could have seen this earlier.

Stefan

[Martin Zibricky]

Stefan Fruehwirth píše v Pá 21. 01. 2011 v 07:13 -0800:

> Damn! I'm so sorry! I forgot to check where the python entry in my
> $PATH points to - it is ActiveState. I don't remeber why I installed
> it on this machine. As I'm usually using 2.5 I didn't pay much
> attention to this and only checked the version with python --version.
>
> I'll try it with python.org later, and let you know whether it works.
>
> Sorry for wasting your time, I could have seen this earlier.
>
> Stefan

Great to hear that we know the cause of this issue.

We should clearly state on pyinstaller website that it is know to not
work with ActivePython, at least on windows platform.

[Stefan Fruehwirth]

On 21 Jan., 16:13, Stefan Fruehwirth <stefan.fruehwi...@uni-graz.at>
wrote:

> I'll try it with python.org later, and let you know whether it works.

Yes, it works with 2.6.6 from python.org. Thanks for the help, sorry
for the missing info!

Stefan

[Martin Zibricky]

Stefan Fruehwirth píše v Pá 21. 01. 2011 v 13:48 -0800:

> Yes, it works with 2.6.6 from python.org. Thanks for the help, sorry
> for the missing info!

I'm glad that the issue is resolved ;)