SetupDiGetClassDevsEx in VC++

  • Thread starter Thread starter Craig Graham
  • Start date Start date
C

Craig Graham

I am trying to use SetupDiGtClassDevsEx from Visual C++. I have the latest
DDK.

I can build samples such as devcon using "build", but whenever I try a
simple test using this one function in VC++ I get a linker error;

devcon2-cg error LNK2001: unresolved external symbol "void * __stdcall
SetupDiGetClassDevsExA(struct _GUID const *,char const *,struct HWND__
*,unsigned long,void *,char const *,void *)"
(?SetupDiGetClassDevsExA@@$$J228YGPAXPBU_GUID@@PBDPAUHWND__@@KPAX13@Z)

In Tools->Options I have the extra link library path set to
C:\WINDDK\3790\lib\wxp\i386

The includes path is set similarly and would appear to be correct because it
does compile.

I have the same in the Linker->Additional Library Diectories in the
properties of the project.

Switching the linker to verbose reveals that lib files are being loaded from
the directory in which setupapi.lib resides. I know it is there because I
can see it with the "dir" command. Why is the VC++ linker not finding it?

The string "setupapi.lib" does not appear in the verbose linker output. It
is as if it does not know to look in setupapi.lib. Is there a way of forcing
it to look at specific lib files as well as specific directories?
 
Craig Graham said:
I am trying to use SetupDiGtClassDevsEx from Visual C++. I have the latest
DDK.

I can build samples such as devcon using "build", but whenever I try a
simple test using this one function in VC++ I get a linker error;
Click to expand...

Well, MS telephone support got this bit sorted out- there was indeed a field
in which I had to explicitly specify the name of the .lib file- under
Project Properties->Linker->Input, named "Additional Dependencies" or
somesuch as I recall.

The project now builds and links, however on running it I have another
problem that hasn't gone away after a few hours of playing.

This snippet is the bulk of my litle test;

HDEVINFO devs = INVALID_HANDLE_VALUE;
devs = SetupDiGetClassDevs(NULL,
NULL,
NULL,
DIGCF_ALLCLASSES);

I've shifted from the Ex version to simplify things. SetupDiGetClassDevs is
returning nothing. It's not leaving devs set to INVALID_HANDLE_VALUE- VC++
shows it as simply "{void}". A subsequent call to GetLastError returns 127,
which is apparently "Procedure call not found". I've tried several different
functions and got the same result.

Does anyone know what is going on?
 
--------------------
From: "Craig Graham" <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.vc
Subject: Re: SetupDiGetClassDevsEx in VC++
Date: Fri, 1 Aug 2003 22:15:40 +0100


I've shifted from the Ex version to simplify things. SetupDiGetClassDevs is
returning nothing. It's not leaving devs set to INVALID_HANDLE_VALUE- VC++
shows it as simply "{void}". A subsequent call to GetLastError returns 127,
which is apparently "Procedure call not found". I've tried several different
functions and got the same result.

Does anyone know what is going on?
Click to expand...

Not sure exactly what's going on, but ERROR_PROC_NOT_FOUND indicates that
there may be some dependency problem. I suggest running depends.exe on
your application to further investigate.
 
Not sure exactly what's going on, but ERROR_PROC_NOT_FOUND indicates that
there may be some dependency problem. I suggest running depends.exe on
your application to further investigate.
Click to expand...

It seems that all was actually fine. A very helpful MS tech support guy
solved a multitude of problems along the way to getting this working, and in
the end sent me the "devcon" source as a Visual Studio project, ready to
build and play with. It turns out the function was working as expected but
there are problems seeing the result in the Visual Studio debugger; in the
devcon project I get an "unable to evaluate" error, and in my test I just
get void. The fact it doesn't leave it set at INVALID_HANDLE_VALUE means it
has worked, and subsequent functions further down the line work. I just
wasn't trying anything further down the line because I thought I was failing
right at the start.

And because it has worked, the results from GetLastError are meaningless.
It's quite a nasty red herring that it gets set to 127 by the function.
 
Back
Top