SetupDiRemoveDevice fails only on Vista with Invalid Handle,...

  • Thread starter Thread starter Kerem Gümrükcü
  • Start date Start date
K

Kerem Gümrükcü

Hi,

i have some interessting Situation here. I started to port my Application
to Windows Vista32/64 and i have some strange Situation there: On Windows
2000 and XP based System the call to SetupDiRemoveDevice(....) works just
fine, but on Windows Vista based System i get a INVALID_HANDLE Error
and the call fails. What i want to know is, to wich part this Error Code
belongs and
to what Parameter. The First Parameter is a handle to a device information
set
and the second is a pointer to SP_DEVINFO_DATA structure. Both Information
"seems" to be valid, since it hold data and no NULL or Zero Info or
something
weird. Since the first parameter is a handle, at first you will think:"Ok
thats it,
backtrack the variable", but the second pointer to SP_DEVINFO_DATA holds
a so called "opaque handle (DWORD)", a handle to a device instance. So which
one is invalid? Is there a simple way to check this, to check which one is
invalid?

The Application asks (while starting) for Elevation and accepts only a
"real"
administrator and wont start another way. So this is excluded. Addtionally
it
enables all possible privileges the User Token has, so this is also
excluded.

Maybe important to know is that the application calls everything from the
..NET
PInvoke Layer, but i had no problems so far,...it started on Vista (like
many many
other problems solved so far). The first thing that comes to mind is that
some sort
of security restriction breaks my design, but i think i would get a
ACCESS_DENIED or
something like YOU_ARE_NOT_ALLOWED_TO_USE_THIS_ERROR_CODE. Its just
a INVALID_HANDLE,...

Any help would be really great!

Regards

Kerem
 
Maybe important to know is that the application calls everything from the
.NET
PInvoke Layer
Click to expand...

..NET is evil. :-)

Try writing a tiny command-line app in unmanaged C which will do the same.
 
Hi Maxim,
.NET is evil. :-)
Click to expand...

I dont know, but why none here likes .NET? .NET is not
evil, its just fine,...as long as you dont need any assembly
involved. One restriction of the application i am working
on is, that it is not allowed to have any external stuff, it
just has to be one big binary. So "tiny" console or "one
shot" binaries are not allowed.

Why does the application work on Windows 2000 and
XP, but fails on Windows Vista? Do you have any suggestions.
To be honest, i dont think thats an .NET (Layer) issue here,
since it work on prior windows version just fine!

Any ideas,...?

Regards

Kerem
 
Well,

i finally found it and it was not what i expected. A colleague wrote
some parts of the application, some classes plain to speak and he
was using some undocumented functions including the
SetupDiGetClassDevsEx(...)
which is undocumented i found. Switching to the SetupDiGetClassDevs(...)
made
everything just work fine.

But SetupDiGetClassDevsEx(...) works on W2K and XP just fine, but fails
with a INVALID_HANDLE_VALUE on Windows Vista. But now it has been
solved. Maybe they changed internals,...obvious they did,...

Thats why i always "try to avoid undocumented stuff,....!

BTW:

Is CM_Uninstall_DevNode(Ex)(...) the same as SetupDiRemoveDevice(...)?
Do you know anything,...?

Regards

Kerem
 
Hi,
What was MachineName argument of ClassDevsEx?
Click to expand...

It was something like "\\MACHINAME". I know these
backslasches are sometimes really necesssary. But the
function did not return any error codes, thas the strange
thing here!

Regards

Kerem
 
Kerem,
Well,

i finally found it and it was not what i expected. A colleague wrote
some parts of the application, some classes plain to speak and he
was using some undocumented functions including the
SetupDiGetClassDevsEx(...)
which is undocumented i found.
Click to expand...

Nope, SetupDiGetClassDevsEx is documented. IIRC I used it already at W2K
times.
 
Did you actually need to call this function for a specific machine? Or it
was always a current machine?
 
Well,

the application mostly uses the Ex-Variants of the Functions
for future remote usage,...

Regards

Kerem
 
involved. One restriction of the application i am working
on is, that it is not allowed to have any external stuff, it
just has to be one big binary
Click to expand...

Yet another evil and silly requirement. Add a native unmanaged DLL there, which will wrap around the non-.NET friendly SetupDi stuff.
 
..NET is extremely useful for what it was designed for - simple GUI apps.
Hardly anyone here will ever work on one of those so it isn't surprising the
general attitude you see ;)
 
.NET is extremely useful for what it was designed for - simple GUI apps.

Correct. It's rapid application development tool, like Delphi.
 
Hello!
.NET is extremely useful for what it was designed for - simple GUI
apps.
Click to expand...

Sorry but this is non-sense. .NET never has been designed for simple GUI
apps.

Do you know the platform you're talking about?


GP
 
Sorry but this is non-sense. .NET never has been designed for simple GUI
apps.
Click to expand...

I love .NET GUIs! The standard controls need a little improvement but
you can create the UI in zero time (and usually it's not simple at all
- in MFC you 'd need days to do all this work...).

It has a few limitations (as a Win32 wrapper) but I hope future
versions of .NET will be much better. :)
 
Do you know the platform you're talking about?

Surely.

Decrease in quality in lots of MS's software (rewritten to .NET) in ~Vista timeframe is a noticeable fact.

So: good tool for ASP.NET and for simple GUI apps. Good replacement for VB and Delphi, bad as a general development tool.
 
Decrease in quality in lots of MS's software (rewritten to .NET) in
~Vista timeframe is a noticeable fact.
Click to expand...

Please cite one classic Windows app that was rewritten in .NET from XP
to Vista.
 
I ment on recent version of .NET (in 2003) problems with big structure
marshalings. It was fixed, but anyway, some problems existed ...
 
IMO the context of this NG doesn't suppose general development tasks
or problems :)

..NET as any other technology is good if you know where to apply it.
 
Hello again!

Just to clarify (this maybe the wrong topic for the kernel-dev group):

The .NET Platform is surly not a Environment that shall be used for
"Low-Level" Applications. Kernel Mode Development is not possible at all,
and User-Mode Windows APIs are desiged to be used in a C Environment.
Allthough .NET has a strong P-Invoke Layer which allows Developers to use
most API Functions (allmost all User-Mode APIs can also be called from
..NET), it takes much longer to code, and it takes much longer to test.

Using .NET for a Product that needs eighter very many or very complex APIs
is of cause not a good choice.

But saying that .NET is just (another) RAD Tool (like Delphi or VB<=6) is
also wrong. The .NET Platform targets all kind of environments, not only
Windows GUIs. My personal Opinion is that System.Windows.Forms is one of the
Modules in .NET that are not really good (in case of Performance and
Resource-Usage). I cannot speak about WPF because I haven't used it until
now. Microsoft has done big investments in the .NET Platform, and it still
does. For very many modern Apps it is very well suited.

Like using .NET for "Low-Level" Dev-Work is a wrong choice, using C(++) for
e.g. an Web-Service based Application Server or a modern Web-Application is
also not very efficient.

If a Product needs some Low-Level stuff why not code them in C(++), and use
COM, P-Invoke or C++/CLI to make it accessable for .NET?


GP
 
Back
Top