Device Manager and devcon do not remove driver service entries for PNP drivers on uninstall

It seems that the Device manager and devcon.exe do not actually remove the service associated with
a driver when uninstalling a device from the system. Additionally, it does not look like the SetupDi...
api supports this functionality. Both tools are properly removing device instances in my case, but
the service entries are left behind in the registry, and the driver binary files are left on the system.
This happens on both XP and W2K3. Looking through the docs there doesn't seem to be a PNP way
to remove them. DeleteService() and manual delete of the binaries seems to be the only way to get
everything off the system. There is an api to remove OEM .inf and .pnf files, but not a driver service
or binaries.

Is this on purpose, or was this an accidental omission from the PNP install support?
Is this going to be a problem in WHQL validation of a driver package?
Is there something I'm missing?

Tom Sanfippo

Eliyas
Mon May 03 19:13:56 CDT 2004

> Is this on purpose, or was this an accidental omission from the PNP
> install support?

I was told that it's by design. Personally I'm not convinced with that
response.


> Is this going to be a problem in WHQL validation of a driver package?

No

> Is there something I'm missing?

No, you are right, there is no INF way of deleting the service key, but
nothing bad happens if you leave that around. So don't worry.


--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

Mark
Sun May 09 10:14:43 CDT 2004

Well nothing bad happens, but as has been pointed out here repeatedly, your
test system is no longer useful in this state for 'clean install' testing.
This, along with the similar enum key problem, are huge annoyances, whose
current solutions require either a combination of scripted and manual
cleanup techniques or brute force rebuilding of the test system either
through ghosting or variations on ipl.

Vendors may also have issues with leaving licensed software on systems that
have decided to uninstall their products.

--

=====================
Mark Roddy
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com


"Eliyas Yakub [MSFT]" <eliyasy@online.microsoft.com> wrote in message
news:uZqLyyWMEHA.644@tk2msftngp13.phx.gbl...
> > Is this on purpose, or was this an accidental omission from the PNP
> > install support?
>
> I was told that it's by design. Personally I'm not convinced with that
> response.
>
>
> > Is this going to be a problem in WHQL validation of a driver package?
>
> No
>
> > Is there something I'm missing?
>
> No, you are right, there is no INF way of deleting the service key, but
> nothing bad happens if you leave that around. So don't worry.
>
>
> --
> -Eliyas
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx
>
>

Ray
Mon May 10 18:55:39 CDT 2004

May I say that *sooooo* much changes on a machine even just every time
that you boot that the "brute force" solution of reghosting your test
machine to a clean OS install is probably a pretty good idea? It doesn't
actually take that long, at least on the SQA timescale... You should
test on a "dirty" system too, so it's not a total waste :-).

One can hope that the LDK driver store scheme will improve this
situation, though... (please, please, please, make it easy to *cleanly*
uninstall a package and the associated cruft, MS...).

Mark Roddy wrote:

> Well nothing bad happens, but as has been pointed out here repeatedly, your
> test system is no longer useful in this state for 'clean install' testing.
> This, along with the similar enum key problem, are huge annoyances, whose
> current solutions require either a combination of scripted and manual
> cleanup techniques or brute force rebuilding of the test system either
> through ghosting or variations on ipl.
>
> Vendors may also have issues with leaving licensed software on systems that
> have decided to uninstall their products.
>

Mark
Wed May 12 18:03:32 CDT 2004

Oh I agree with the brute force approach, it is the only one that actually
guarantees a repeatable test. However, that said, a tool that actually did
the complete driver clean up automatically would allow isolating the 'driver
clean install test case' to a simple procedure that could even be easily
automated.

--

=====================
Mark Roddy
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com


"Ray Trent" <rat@synaptics.com.spamblock> wrote in message
news:%232pRNpuNEHA.3016@tk2msftngp13.phx.gbl...
> May I say that *sooooo* much changes on a machine even just every time
> that you boot that the "brute force" solution of reghosting your test
> machine to a clean OS install is probably a pretty good idea? It doesn't
> actually take that long, at least on the SQA timescale... You should
> test on a "dirty" system too, so it's not a total waste :-).
>
> One can hope that the LDK driver store scheme will improve this
> situation, though... (please, please, please, make it easy to *cleanly*
> uninstall a package and the associated cruft, MS...).
>
> Mark Roddy wrote:
>
> > Well nothing bad happens, but as has been pointed out here repeatedly,
your
> > test system is no longer useful in this state for 'clean install'
testing.
> > This, along with the similar enum key problem, are huge annoyances,
whose
> > current solutions require either a combination of scripted and manual
> > cleanup techniques or brute force rebuilding of the test system either
> > through ghosting or variations on ipl.
> >
> > Vendors may also have issues with leaving licensed software on systems
that
> > have decided to uninstall their products.
> >