[python-win32] Error R6034 when I import uuid

[Blair Hall]

You might consider double-checking your message subjects before
responding. That's especially important when you read the digest.

Oh dear, I am sorry. I hadn't twigged to how that worked. I have restored
the original subject now, from my initial post. Hope that helps.

Can you show us your manifest?
Thanks for taking a look.

http://stackoverflow.com/questions/29597999/incorrect-dll-is-loaded-from-windows-path-instead-of-manifest

My understanding was that the operating system should look for the
manifest, but, well, it doesn't seem to be doing that for me. :-(

Well, here's the thing that makes this tricky. The manifest you showed
is associated with the library, not with your DLL. It is telling the
system which version of the CRT is included in your Microsoft.VC90.CRT
folder. But unless you have a manifest associated with your
application, there's nothing that tells the system to go look for that
specific version. By default, it will go searching for the newest one.

Just to be clear, I showed you the manifest that I have provided in my
project, as recommended when distributing py2exe executables (see here:
http://www.py2exe.org/index.cgi/Tutorial#Step521). Note too, that I have
also tried the redistributable C runtime installer from Microsoft on the
target machines, but that didn't change anything: if there is a version of
msvcr90.dll in the Windows PATH, that gets used.

The DLL itself has an embedded manifest (generated automatically by py2exe,
with no help from me) I have now added that to the stackoverflow page, so
you can see it.

One ugly alternative would be to edit sys.path in your code before you

start your imports. If you remove everything but the Windows
directories, that should solve the problem.

I don't follow. Surely sys.path has nothing to do with it? It is the
LoadLibrary("msvcr90") call from _cytpes.pyd that seems to be the problem
here and that is not using the sys.path (or is it?).

For what its worth, here are some more of my own thoughts.

I have used py2exe on another project that creates an EXE. This project
also imports uuid (it basically imports the same stuff I am using now, but
for a different application). In that case, the manifest seems to work as
expected. So, I wonder what is different in the case of my DLL? Well one
thing that I can think of is that the problem arises when registering the
DLL as a COM server, using regsvr32. Could it be that Windows does not know
to look for the manifest in the right place because it is regsvr32 that is
running?!

[Tim Roberts]

Post by Blair Hall
One ugly alternative would be to edit sys.path in your code before you
start your imports. If you remove everything but the Windows
directories, that should solve the problem.
I don't follow. Surely sys.path has nothing to do with it? It is the
LoadLibrary("msvcr90") call from _cytpes.pyd that seems to be the
problem here and that is not using the sys.path (or is it?).

Absolutely, yes. DLLs are found through the path exactly like any other
executable. You can read about the DLL search algorithm in excruciating
detail here, although this omits some of the ugly subtleties of the
side-by-side nonsense used by msvcr90 and friends:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx

Post by Blair Hall
I have used py2exe on another project that creates an EXE. This
project also imports uuid (it basically imports the same stuff I am
using now, but for a different application). In that case, the
manifest seems to work as expected. So, I wonder what is different in
the case of my DLL? Well one thing that I can think of is that the
problem arises when registering the DLL as a COM server, using
regsvr32. Could it be that Windows does not know to look for the
manifest in the right place because it is regsvr32 that is running?!

It's not that easy. As I said, the manifest you have provided is not
actually connected to your DLL. It merely lets the operating system
know about the runtime library that you have included. If the DLL
search path comes to your folder, the fact that you have provided a
manifest means that the system is allowed to find your version of
msvcr90. If there is someone else earlier in the search order that also
has one, it will find that one instead.

[Blair Hall]

Post by Blair Hall
I have used py2exe on another project that creates an EXE. This

Post by Blair Hall
project also imports uuid (it basically imports the same stuff I am
using now, but for a different application). In that case, the
manifest seems to work as expected. So, I wonder what is different in
the case of my DLL? Well one thing that I can think of is that the
problem arises when registering the DLL as a COM server, using
regsvr32. Could it be that Windows does not know to look for the
manifest in the right place because it is regsvr32 that is running?!

It's not that easy. As I said, the manifest you have provided is not
actually connected to your DLL. It merely lets the operating system
know about the runtime library that you have included. If the DLL
search path comes to your folder, the fact that you have provided a
manifest means that the system is allowed to find your version of
msvcr90. If there is someone else earlier in the search order that also
has one, it will find that one instead.

I get your point that the first manifest I provided is not specific to the
DLL, but the second (embedded in the DLL) manifest that I posted seems to
identify a particular version of msvcr90.dll. Sadly, Windows does not worry
about matching the version of msvcr90.dll: it just loads the first one it
finds with the correct name. So what is the embedded manifest in the DLL
really there for?

I suppose in the case of my other project that produces an executable,
Windows is going to include the executable folder early in the search path,
so the runtime library is found via the manifest in that case?

Anyway, you say "the manifest you have provided is not actually connected
to your DLL". Is there something that I can do with these manifests so that
there is a connection?

[Tim Roberts]

Post by Blair Hall
I get your point that the first manifest I provided is not specific to
the DLL, but the second (embedded in the DLL) manifest that I posted
seems to identify a particular version of msvcr90.dll. Sadly, Windows
does not worry about matching the version of msvcr90.dll: it just
loads the first one it finds with the correct name. So what is the
embedded manifest in the DLL really there for?

There's a "greater than or equal to" aspect to this as well. There is a
way for a package to say "I can also be loaded when apps ask for earlier
releases".

There can also be a conflict between the needs of an EXE and the needs
of a DLL. If the EXE has a manifest that requests a certain version of
the CRT, then a DLL can't really override it.

You have an ugly, icky problem, and I'm not quite sure what to advise
you. The traces you are showing don't necessarily match with what I
would have expected. I don't understand why the Intel version of the
CRT is getting chosen, and I don't understand why it's failing to link
up with it again later.

[Blair Hall]

Post by Tim Roberts

Post by Blair Hall
I get your point that the first manifest I provided is not specific to
the DLL, but the second (embedded in the DLL) manifest that I posted
seems to identify a particular version of msvcr90.dll. Sadly, Windows
does not worry about matching the version of msvcr90.dll: it just
loads the first one it finds with the correct name. So what is the
embedded manifest in the DLL really there for?

There's a "greater than or equal to" aspect to this as well. There is a
way for a package to say "I can also be loaded when apps ask for earlier
releases".
There can also be a conflict between the needs of an EXE and the needs
of a DLL. If the EXE has a manifest that requests a certain version of
the CRT, then a DLL can't really override it.
You have an ugly, icky problem, and I'm not quite sure what to advise
you. The traces you are showing don't necessarily match with what I
would have expected. I don't understand why the Intel version of the
CRT is getting chosen, and I don't understand why it's failing to link
up with it again later.

Oh well, thanks for trying.

Google searches on this type of problem throw up a few other instances that
look similar, but I have not found a definitive answer. Perhaps it's simply
old technology and people have moved on. I suppose that if I were using
Python 3.x there would be no problems at all.

I have a work-around (wrote my own version of the function I needed from
the uuid module), so I might not have to worry about this anymore, but if
anyone finds this thread and has an answer, I'd sure like to know.