SetupOpenInfFile returns ERROR_PROC_NOT_FOUND on Windows 7 RC x64 Edition

[Stefan Kuhr]

Hello everyone,

I dunno if it is okay to post questions here regarding unreleased
versions of windows, so please, folks, point me somewhere else if this
is the case.

I am currently testing our product (userland, entirely, compiled for
x86) on Windows 7 x64 Edition RC and encountered a strange error: We
call SetupOpenInfFile from a DLL of ours and Windows 7 x64 edition fails
for us here with last error 127 (ERROR_PROC_NOT_FOUND). This runs well
on all versions since Windows 2000 up to and including the x86 edition
of Windows 7 RC. The code for this has been unchanged since years.

I also added a call to SetupGetInfInformation and it fails with the same
last error, so I assume that a lot more calls into setupapi.dll fail in
the same way. Just for fun I added a global object to our DLL with a
call to SetupOpenInfFile in its constructor (I know I should not do such
things in globals since this is equivalent to adding code in DllMain)
and surprisingly, with this global added, the calls to SetupOpenInfFile
from within exported functions of the DLL suddenly succeed.

How can I further troubleshoot what's going on here? Any idea what might
be the problem? Any wild guesses are accepted...

--
Stefan Kuhr

[Pavel A.]

Hi Stefan,

The Win7 beta forums are here:
http://social.technet.microsoft.com/Forums/en/category/w7itpro

-- pa

[Tim Roberts]

Stefan Kuhr <kust...@gmx.li> wrote:
>
>I am currently testing our product (userland, entirely, compiled for
>x86) on Windows 7 x64 Edition RC and encountered a strange error: We
>call SetupOpenInfFile from a DLL of ours and Windows 7 x64 edition fails
>for us here with last error 127 (ERROR_PROC_NOT_FOUND). This runs well
>on all versions since Windows 2000 up to and including the x86 edition
>of Windows 7 RC. The code for this has been unchanged since years.

>...

>How can I further troubleshoot what's going on here? Any idea what might
>be the problem? Any wild guesses are accepted...

Devcon, at least, does not operate correctly when the 32-bit binary is run
on a 64-bit system. Does your app work if you compile it for x64?
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Stefan Kuhr]

Hello Tim,

I know that devcon doesn't run on x64, because e.g.
UpdateDriverForPlugAndPlayDevices must run natively in a x64 binary. But
this is not the point in my scenario, even a SetupOpenInfFile fails, and
that call is not even used at this point for driver installation, we
simply use the inf format and the inf file routines from setupapi.dll as
a better replacement for ini file calls.

Porting our app to x64 is currently not feasible as it is really huge
and has quite some history. It would take months or years to do that.

--
Stefan

[Gottfried Stöckl]

Dear Stefan,

If I understood you well, you try to make calls from a 32Bit-dll running on
a 64Bit target...
So therefore you will be running in WOW64 mode (Refer to this article:
http://msdn.microsoft.com/en-us/library/aa384274(VS.85).aspx)

Furthermore dll-calls from within your dll (in your case setupapi.dll) must
be redirected to the 32bit pendants of the os as well. So it might be, that
during initialization of you dll (where your static constructors are being
called) the module state is not already defined, therefore this could be the
reason why later calls will not fail. BUT: I presume, that the propability is
high, that you will run into strange behavements later if you continue using
this workaround ;-)

Maybe there is a kind of bug in the 32bit version of the setupapi.dll under
windows 7, so first try to run the same dll also under vista64 for more
clearity.
I hope, you will not try to copy your own version of setupapi.dll to target,
even though it would run nicely on your 32bit reference platform, it is
binary incompatible.

Try to run dependency walker with your dll (there exists a 64 bit version at
microsoft.com). This helps you to identify such a problem.

I also would try to delay load the functions of the setupapi.dll.
Remove the .lib file from your project and use LoadLibrary with
GetProcAddress.
Then cast the returned pointer to a function pointer that matches the
declaration of the setupapi function and call it.

[Stefan Kuhr]

Hi Gottfried,

Gottfried Stöckl wrote:
> Dear Stefan,
>
> If I understood you well, you try to make calls from a 32Bit-dll running on
> a 64Bit target...
> So therefore you will be running in WOW64 mode (Refer to this article:
> http://msdn.microsoft.com/en-us/library/aa384274(VS.85).aspx)
>

Thanks, I knew this already.

> Furthermore dll-calls from within your dll (in your case setupapi.dll) must
> be redirected to the 32bit pendants of the os as well. So it might be, that
> during initialization of you dll (where your static constructors are being
> called) the module state is not already defined, therefore this could be the
> reason why later calls will not fail. BUT: I presume, that the propability is
> high, that you will run into strange behavements later if you continue using
> this workaround ;-)

This is not a workaround. It is an experiment that I made for fun.

>
> Maybe there is a kind of bug in the 32bit version of the setupapi.dll under
> windows 7, so first try to run the same dll also under vista64 for more
> clearity.

As I wrote, it works for Windows 2000 up to Win 7 x86, this includes
Vista x64, and it works quite nicely on Vista x64.

> I hope, you will not try to copy your own version of setupapi.dll to target,
> even though it would run nicely on your 32bit reference platform, it is
> binary incompatible.

We don't do such things. WFP will prevent that anyway.

>
> I also would try to delay load the functions of the setupapi.dll.
> Remove the .lib file from your project and use LoadLibrary with
> GetProcAddress.
> Then cast the returned pointer to a function pointer that matches the
> declaration of the setupapi function and call it.

The DLL has setupapi.dll already delayloaded. However, it doesn't make a
difference whether I delayload setupapi.dll in this DLL or not. From
process explorer I can see that setupapi.dll has been fully loaded.

Thanks for your suggestions,

--
S

[Stefan Kuhr]

Hello everyone,

I have further investigated what is going on and this is what happens:

SetupOpenInfFile internally calls into spinf.dll that is delayloaded by
setupapi.dll, the function it calls is SpInfLoadInfFile. Now in the case
where the calls into SetupOpenInfFile fail with last error 0x7F=127
(ERROR_PROC_NOT_FOUND), it actually doesn't call into SpInfLoadInfFile
but instead into kernel32's MtxCluIsClusterPresent function. This
function does a mere

push 0x7F
pop eax

and obviously this return value then bubbled up as the last error of
SetupOpenInfFile. I found that MtxCluIsClusterPresent is called because
someone obviously overwites the IAT entries of setupapi.dll with this
export from kernel32.dll. This happens during a previous call into
setupapi.dll's SetupDiBuildDriverInfoList in our function
FindCurrentDriver, that we stole from devcon.

Unfortunately I haven't been able to reduce all this to a simple to
reproduce sample project. So if anyone has an idea what might lead to
those crazy things happening, please let me know. For now I have
excluded the call into above mentioned function FindCurrentDriver,
stolen from devcon, when running on Win7 x64, because it is on an error
path in our software when running as an x86 binary on x64 anyway, so we
would call a fallback implementation later anyway (we try to determine
the inf file that is associated with a device with FindCurrentDriver).

--
Stefan

Prior to the call to the call to SetupOpenInfFile that fails with

[Pavel A.]

Very interesting, hope somebody from MS notices this! thanks! - pa

[Mike [MSFT]]

I think you may be seeing a side effect of the way delayload handles errors.
When you make a call into a delayloaded module it will only make one attempt
to load the module and get the proc address. If that fails then all
subsequent calls just get mapped directly to the failure. What you'll need
to do is find the very first call that the process makes into that library
and step into that.

Another way to test this out is to make an explicit
LoadLibrary/GetProcAddress call as soon as your process is created. That
should also fail and give you more information.

-Mike

"Pavel A." <pav...@NOfastmailNO.fm> wrote in message
news:uyYXAtX$JHA....@TK2MSFTNGP03.phx.gbl...