unknown device issues after running winetest

[Paul Vriens]

Hi,

On several windows boxes (VMware) I receive this nice message that Windows will 
try to find a driver for an unknown device.

This device is added by the setupapi/devinst test and is not (or can't be?) 
properly removed after the tests.

On NT/W2K I'm able to delete all the relevant registry keys (regedt32.exe) but 
on Vista I don't seem to be able to delete them

Any idea? Do others have the same issue(s) ?

[Paul Vriens]

Paul Vriens wrote:
> Hi,
>
> On several windows boxes (VMware) I receive this nice message that 
> Windows will try to find a driver for an unknown device.
>
> This device is added by the setupapi/devinst test and is not (or can't 
> be?) properly removed after the tests.
>
> On NT/W2K I'm able to delete all the relevant registry keys 
> (regedt32.exe) but on Vista I don't seem to be able to delete them
>
> Any idea? Do others have the same issue(s) ?

OK, I managed to remove the registry keys from Vista as well. Took only 75 
mouseclicks :-(

The issue about the leftover registry keys after the tests still stands though.

[Maarten Lankhorst]

Hello Paul,

2008/5/20 Paul Vriens :
> Paul Vriens wrote:
> > Hi,
> >
> > On several windows boxes (VMware) I receive this nice message that
> > Windows will try to find a driver for an unknown device.
> >
> > This device is added by the setupapi/devinst test and is not (or can't
> > be?) properly removed after the tests.
> >
> > On NT/W2K I'm able to delete all the relevant registry keys
> > (regedt32.exe) but on Vista I don't seem to be able to delete them
> >
> > Any idea? Do others have the same issue(s) ?
>
> OK, I managed to remove the registry keys from Vista as well. Took only 75
> mouseclicks :-(
>
> The issue about the leftover registry keys after the tests still stands though.

I just keep hitting escape when booting, but it is a real problem that
should be addressed, anyone knows the exact testing causing the
creation of the dummy devices? Why 75 mouse clicks, uac in the way?

Cheers,
Maarten.

[Juan Lang]

> anyone knows the exact testing causing the creation of the dummy devices?

I believe it's testRegisterDeviceInfo.  See my comment in it:
* FIXME: the key also becomes undeletable.  How to get rid of it?

--Juan

[James Hawkins]

On Tue, May 20, 2008 at 8:17 PM, Juan Lang  wrote:
> > anyone knows the exact testing causing the creation of the dummy devices?
>
> I believe it's testRegisterDeviceInfo.  See my comment in it:
> - FIXME: the key also becomes undeletable.  How to get rid of it?

Another note: the tests can only be run successfully once (assuming no
other failures), but if the tests are run again without a reboot, we
get ~30 failures.  I'm assuming that has to do with the undeletability
(nice fake word) of the device keys.

[Paul Vriens]

James Hawkins wrote:
> On Tue, May 20, 2008 at 8:17 PM, Juan Lang  wrote:
> > > anyone knows the exact testing causing the creation of the dummy devices?
> >
> > I believe it's testRegisterDeviceInfo.  See my comment in it:
> > - FIXME: the key also becomes undeletable.  How to get rid of it?
>
> Another note: the tests can only be run successfully once (assuming no
> other failures), but if the tests are run again without a reboot, we
> get ~30 failures.  I'm assuming that has to do with the undeletability
> (nice fake word) of the device keys.

It appears that the regsitry keys are owned by SYSTEM. On W2K3 it's services.exe 
(haven't checked the other OS's) that creates/modifies these registry keys. So 
they can't be deleted by simply doing a RegDeleteKey in the tests.

Any idea what the best approach is to programatically change the permissions (or 
owner) of these keys so we're able to delete them?

[Paul Vriens]

Juan Lang wrote:
> > anyone knows the exact testing causing the creation of the dummy devices?
>
> I believe it's testRegisterDeviceInfo.  See my comment in it:
> - FIXME: the key also becomes undeletable.  How to get rid of it?
>
> --Juan

Deleting is not an issue if you use the native GUI's. You first have to set the 
correct permissions though. In later version of regedit.exe you can do this from 
this gui, in older cases you have to use regedt32.exe

Not sure (yet) if we can do this in/from our code.

[Paul Vriens]

Juan Lang wrote:
> > anyone knows the exact testing causing the creation of the dummy devices?
>
> I believe it's testRegisterDeviceInfo.  See my comment in it:
> - FIXME: the key also becomes undeletable.  How to get rid of it?
>
> --Juan

Hi Juan,

Are the tests in devinst.c supposed so be run in order? IOW are they supposed to 
bee cleaned up after each subtest or do they rely on each other?

[Juan Lang]

Hi Paul,
> Are the tests in devinst.c supposed so be run in order? IOW are they
> supposed to bee cleaned up after each subtest or do they rely on each other?

I'm sure I didn't put that much thought into making the tests order
dependent.  I wrote them, ran them, made them into tests, and they
worked at least once for me.  I might not have tested running them
subsequent times on the same machine.

I don't think it's a general problem with the devinst.c tests.  There
are two problems with them:
1. Some of the last error checks fail on some versions of Windows.  I
only have Windows XP, so I couldn't have anticipated these.  James is
doing a nice job of cleaning them up (thanks James.)
2. The call to SetupDiRegisterDeviceInfo leaves keys around that are
hard to delete, and cause subsequent runs of the test to fail.

In my opinion it's probably okay to remove the
SetupDiRegisterDeviceInfo tests.  I don't know any apps that call this
API directly.
--Juan

[Paul Vriens]

Juan Lang wrote:
> Hi Paul,
> > Are the tests in devinst.c supposed so be run in order? IOW are they
> > supposed to bee cleaned up after each subtest or do they rely on each other?
>
> I'm sure I didn't put that much thought into making the tests order
> dependent.  I wrote them, ran them, made them into tests, and they
> worked at least once for me.  I might not have tested running them
> subsequent times on the same machine.
>
> I don't think it's a general problem with the devinst.c tests.  There
> are two problems with them:
> - Some of the last error checks fail on some versions of Windows.  I
>
> only have Windows XP, so I couldn't have anticipated these.  James is
> doing a nice job of cleaning them up (thanks James.)
> 2. The call to SetupDiRegisterDeviceInfo leaves keys around that are
> hard to delete, and cause subsequent runs of the test to fail.
>
> In my opinion it's probably okay to remove the
> SetupDiRegisterDeviceInfo tests.  I don't know any apps that call this
> API directly.
> --Juan

Now you tell me :-).

I've something in place already to get rid of the stray registry keys. Just 
needs some more thought and tweaking.

[Juan Lang]

> Now you tell me :-).
>
> I've something in place already to get rid of the stray registry keys. Just
> needs some more thought and tweaking.

Well that's even better!  Feel free to send here for comments :)
--Juan

[Paul Vriens]

Juan Lang wrote:
> > Now you tell me :-).
> >
> > I've something in place already to get rid of the stray registry keys. Just
> > needs some more thought and tweaking.
>
> Well that's even better!  Feel free to send here for comments :)
> --Juan

It's a new function that just changes the permissions:

static void change_reg_permissions(CHAR *regkey)
{
     HKEY hkey;
     SID_IDENTIFIER_AUTHORITY ident = { SECURITY_WORLD_SID_AUTHORITY };
     SECURITY_DESCRIPTOR sd;
     PSID EveryoneSid;
     PACL pacl = NULL;

RegOpenKeyExA(HKEY_LOCAL_MACHINE, regkey, 0, WRITE_DAC, &hkey);

/* Initialize the 'Everyone' sid */
     AllocateAndInitializeSid(&ident, 1, SECURITY_WORLD_RID, 0, 0, 0, 0, 0, 0, 
0, &EveryoneSid);

pacl = HeapAlloc(GetProcessHeap(), 0, 256);
     InitializeAcl(pacl, 256, ACL_REVISION);

/* Add 'Full Control' for 'Everyone' */
     AddAccessAllowedAce(pacl, ACL_REVISION, KEY_ALL_ACCESS, EveryoneSid);

InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION);

SetSecurityDescriptorDacl(&sd, TRUE, pacl, FALSE);

/* Set the new security on the registry key */
     RegSetKeySecurity(hkey, DACL_SECURITY_INFORMATION, &sd);

RegCloseKey(hkey);

HeapFree(GetProcessHeap(), 0, pacl);
     if (EveryoneSid)
         FreeSid(EveryoneSid);
}

Now we are able to remove the registry keys. Works fine on NT4, didn't test on 
Vista yet.

I didn't find a way yet (and didn't look to hard) to make the subkeys inherit 
these new permissions. Otherwise I have to do this for every key.

[Juan Lang]

> I didn't find a way yet (and didn't look to hard) to make the subkeys
> inherit these new permissions. Otherwise I have to do this for every key.

I don't think you can if you don't actually create the key.  The
caller of RegCreateKeyEx is able to set the default DACL for the key,
and subkeys will inherit this if they don't set their own DACL.  In
this case we expect that some system process is creating the key, so
we have to change the DACL after the fact.

In other words, I think your function looks fine :)
--Juan

[Paul Vriens]

Juan Lang wrote:
> > I didn't find a way yet (and didn't look to hard) to make the subkeys
> > inherit these new permissions. Otherwise I have to do this for every key.
>
> I don't think you can if you don't actually create the key.  The
> caller of RegCreateKeyEx is able to set the default DACL for the key,
> and subkeys will inherit this if they don't set their own DACL.  In
> this case we expect that some system process is creating the key, so
> we have to change the DACL after the fact.
>
> In other words, I think your function looks fine :)
> --Juan

Ok, I will go ahead and start creating the patches to be able to delete the 
registry keys after each test (if there are leftovers of course).

Currently we will have loads of Windows boxes out there that have bogus registry 
keys. Should I first create a cleanup routine at the start of devinst.c ?

A problem I'm seeing is that more registry keys are added after reboots.
Running the tests on a clean machine adds bogus entries to 
HKLM/SYSTEM/CurrentControlSet and there are 'links' from ControlSet001 for 
example. When I delete them before a reboot the 'links' are gone as well. When I 
however first reboot I've seen occasions where the keys can also be found at 
ControlSet002 (or 003 even). Deleting the keys in CurrentControlSet now doesn't 
remove them from ControlSet002 (or 003).

Another approach is of course to only do the cleanup afterwards which means we 
will have 1 run of tests that will fail.

[Maarten Lankhorst]

Hello Juan,

2008/5/21 Juan Lang :
> > Are the tests in devinst.c supposed so be run in order? IOW are they
> > supposed to bee cleaned up after each subtest or do they rely on each other?
>
> I'm sure I didn't put that much thought into making the tests order
> dependent.  I wrote them, ran them, made them into tests, and they
> worked at least once for me.  I might not have tested running them
> subsequent times on the same machine.
>
> I don't think it's a general problem with the devinst.c tests.  There
> are two problems with them:
> - Some of the last error checks fail on some versions of Windows.  I
>
> only have Windows XP, so I couldn't have anticipated these.  James is
> doing a nice job of cleaning them up (thanks James.)
> 2. The call to SetupDiRegisterDeviceInfo leaves keys around that are
> hard to delete, and cause subsequent runs of the test to fail.
>
> In my opinion it's probably okay to remove the
> SetupDiRegisterDeviceInfo tests.  I don't know any apps that call this
> API directly.

My ipod patches (if they ever make it in) use them to register the ipod device.

Cheers,
Maarten.

[James Hawkins]

On Tue, May 20, 2008 at 8:08 PM, Maarten Lankhorst
 wrote:
> Hello Paul,
>
> 2008/5/20 Paul Vriens :
> > Paul Vriens wrote:
> > > Hi,
> > >
> > > On several windows boxes (VMware) I receive this nice message that
> > > Windows will try to find a driver for an unknown device.
> > >
> > > This device is added by the setupapi/devinst test and is not (or can't
> > > be?) properly removed after the tests.
> > >
> > > On NT/W2K I'm able to delete all the relevant registry keys
> > > (regedt32.exe) but on Vista I don't seem to be able to delete them
> > >
> > > Any idea? Do others have the same issue(s) ?
> >
> > OK, I managed to remove the registry keys from Vista as well. Took only 75
> > mouseclicks :-(
> >
> > The issue about the leftover registry keys after the tests still stands though.
>
> I just keep hitting escape when booting, but it is a real problem that
> should be addressed, anyone knows the exact testing causing the
> creation of the dummy devices? Why 75 mouse clicks, uac in the way?

It should be mentioned that the setupapi:devinst tests fail miserably
on every platform.  I'm working through the failing win2k3 tests, but
it would be nice if someone could take a look at these, maybe even
those that contributed to or wrote the tests.

Thanks,
James Hawkins

[Paul Vriens]

James Hawkins wrote:
> It should be mentioned that the setupapi:devinst tests fail miserably
> on every platform.  I'm working through the failing win2k3 tests, but
> it would be nice if someone could take a look at these, maybe even
> those that contributed to or wrote the tests.
>
> Thanks,
> James Hawkins

I've been looking (every now and then) at these tests. One of the issues is that 
several of these tests act totally different on the different Windows version.

Now that I know I'm not the only once suffering from these 'unknown devices' I 
will have a closer look (if time permits).

And I second the call for the contributor(s) of the test to have a look as well.

[Paul Vriens]

Maarten Lankhorst wrote:
> > The issue about the leftover registry keys after the tests still stands though.
>
> I just keep hitting escape when booting, but it is a real problem that
> should be addressed, anyone knows the exact testing causing the
> creation of the dummy devices? Why 75 mouse clicks, uac in the way?

Yes, it 's UAC. You first have to make yourself owner of the regkey and then add 
  the proper permissions. In this particular case it turns out there are several 
hidden (not enough permissions to view) keys and you have do to the same thing 
again to those and the ones underneath and ......

[Alexander Morozov]

В сообщении от Tuesday 20 May 2008 17:31:48 Paul Vriens написал(а):
> Hi,
>
> On several windows boxes (VMware) I receive this nice message that Windows
> will try to find a driver for an unknown device.
>
> This device is added by the setupapi/devinst test and is not (or can't be?)
> properly removed after the tests.
>
> On NT/W2K I'm able to delete all the relevant registry keys (regedt32.exe)
> but on Vista I don't seem to be able to delete them
>
> Any idea? Do others have the same issue(s) ?

Hi,

I added testRegisterAndGetDetail and testDeviceRegistryPropertyA/W. I am sorry 
for creating discussed problem. I tried to use SetupDiRemoveDeviceInterface, 
SetupDiRemoveDevice and SetupDiDeleteDevRegKey but this is not fixing this 
bug. SetupDiRemoveDevice and SetupDiDeleteDevRegKey do not delete 
Enum/ROOT/LEGACY_BOGUS key (on WinXP at least). Now I do not know the right 
way to delete created keys. May be should use something like Paul Vriens`s 
change_reg_permissions.

[Alexander Morozov]

I was mistaken. Enum/ROOT/LEGACY_BOGUS key can be deleted so:

SetLastError(0xdeadbeef);
set = pSetupDiGetClassDevsA(&guid, NULL, 0, 0);
ok(set != INVALID_HANDLE_VALUE, "SetupDiGetClassDevsA failed: %08x\n", 
GetLastError());
SetLastError(0xdeadbeef);
ret = pSetupDiEnumDeviceInfo(set, 0, &devInfo);
ok(ret, "SetupDiEnumDeviceInfo failed: %08x\n", GetLastError());
if (pSetupDiRemoveDevice)
{
    SetLastError(0xdeadbeef);
    ret = pSetupDiRemoveDevice(set, &devInfo);
    todo_wine
    ok(ret, "SetupDiRemoveDevice failed: %08x\n", GetLastError());
}
else
    skip("SetupDiRemoveDevice is not available\n");
pSetupDiDestroyDeviceInfoList(set);

[Paul Vriens]

Alexander Morozov wrote:
> I was mistaken. Enum/ROOT/LEGACY_BOGUS key can be deleted so:
>
> SetLastError(0xdeadbeef);
> set = pSetupDiGetClassDevsA(&guid, NULL, 0, 0);
> ok(set != INVALID_HANDLE_VALUE, "SetupDiGetClassDevsA failed: %08x\n", 
> GetLastError());
> SetLastError(0xdeadbeef);
> ret = pSetupDiEnumDeviceInfo(set, 0, &devInfo);
> ok(ret, "SetupDiEnumDeviceInfo failed: %08x\n", GetLastError());
> if (pSetupDiRemoveDevice)
> {
>     SetLastError(0xdeadbeef);
>     ret = pSetupDiRemoveDevice(set, &devInfo);
>     todo_wine
>     ok(ret, "SetupDiRemoveDevice failed: %08x\n", GetLastError());
> }
> else
>     skip("SetupDiRemoveDevice is not available\n");
> pSetupDiDestroyDeviceInfoList(set);

I agree that we should use the appropriate setupapi calls stuff to remove stuff.

I however already found some cases were that won't work. So in the end it will 
most likely be a mix of setupapi calls and manual registry key deletion.

[Paul Vriens]

Alexander Morozov wrote:
> В сообщении от Tuesday 20 May 2008 17:31:48 Paul Vriens написал(а):
> > Hi,
> >
> > On several windows boxes (VMware) I receive this nice message that Windows
> > will try to find a driver for an unknown device.
> >
> > This device is added by the setupapi/devinst test and is not (or can't be?)
> > properly removed after the tests.
> >
> > On NT/W2K I'm able to delete all the relevant registry keys (regedt32.exe)
> > but on Vista I don't seem to be able to delete them
> >
> > Any idea? Do others have the same issue(s) ?
>
> Hi,
>
> I added testRegisterAndGetDetail and testDeviceRegistryPropertyA/W. I am sorry 
> for creating discussed problem. I tried to use SetupDiRemoveDeviceInterface, 
> SetupDiRemoveDevice and SetupDiDeleteDevRegKey but this is not fixing this 
> bug. SetupDiRemoveDevice and SetupDiDeleteDevRegKey do not delete 
> Enum/ROOT/LEGACY_BOGUS key (on WinXP at least). Now I do not know the right 
> way to delete created keys. May be should use something like Paul Vriens`s 
> change_reg_permissions.

Can someone confirm that after running the devinst tests, the registry on Wine 
still shows these:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and stuff below)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff below)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4-3F65-11DB-B704-0011955C2BDB} 
(and stuff below)

If I run 'make devinst.ok' on a clean .wine the tests succeed but leave the 
above registry keys behind.

As the new tests will include several checks about leftover registry keys this 
can be confusing.

If someone can confirm my 'findings' we probably first have to fix setupapi. I 
don't think we should mimic Windows by leaving these registry keys around as I 
think our tests don't do the 'normal' thing when adding devices.

[Alexander Morozov]

> Can someone confirm that after running the devinst tests, the registry on
> Wine still shows these:
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> stuff below)
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> below)
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4
> -3F65-11DB-B704-0011955C2BDB} (and stuff below)

I can confirm this. Diff file with changes after running make devinst.ok is 
attached.

[Paul Vriens]

Alexander Morozov wrote:
> > Can someone confirm that after running the devinst tests, the registry on
> > Wine still shows these:
> >
> > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> > stuff below)
> >
> > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> > below)
> >
> > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4
> > -3F65-11DB-B704-0011955C2BDB} (and stuff below)
>
> I can confirm this. Diff file with changes after running make devinst.ok is 
> attached.

Ok, so at least it looks we are compatible with Windows :-)

I will check out your suggestion about using SetupDiRemoveDevice (and maybe 
SetupDiRemoveDeviceInterface) to clean up the registry.

I already found that it doesn't work on NT4 for everything as we have a bogus 
bogus entry (missing the ClassGUID value). This means you can't even enumerate 
this one and it won't be covered by the remove calls.

So what about a cleanup_before function that gets rid of everything that's 
currently bogus in the registry? If we don't do this before we have to cater for 
existing keys in every test which will clutter the tests I think. If we really 
want to test existing keys we should do so a part of a normal test.

After that cleanup_before is working we can change the tests to clean up after 
themselves.

[James Hawkins]

On Fri, May 23, 2008 at 2:59 AM, Paul Vriens  wrote:
> Alexander Morozov wrote:
> > > Can someone confirm that after running the devinst tests, the registry on
> > > Wine still shows these:
> > >
> > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> > > stuff below)
> > >
> > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> > > below)
> > >
> > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4
> > > -3F65-11DB-B704-0011955C2BDB} (and stuff below)
> >
> > I can confirm this. Diff file with changes after running make devinst.ok is
> > attached.
>
> Ok, so at least it looks we are compatible with Windows :-)
>
> I will check out your suggestion about using SetupDiRemoveDevice (and maybe
> SetupDiRemoveDeviceInterface) to clean up the registry.
>
> I already found that it doesn't work on NT4 for everything as we have a bogus
> bogus entry (missing the ClassGUID value). This means you can't even enumerate
> this one and it won't be covered by the remove calls.
>
> So what about a cleanup_before function that gets rid of everything that's
> currently bogus in the registry? If we don't do this before we have to cater for
> existing keys in every test which will clutter the tests I think. If we really
> want to test existing keys we should do so a part of a normal test.
>
> After that cleanup_before is working we can change the tests to clean up after
> themselves.

Will the new 'cleanup after' code not delete these invalid entries?
One test run is fine to sacrifice for the sake of not cluttering up
the tests with temporary cleanup code.

[Paul Vriens]

James Hawkins wrote:
> On Fri, May 23, 2008 at 2:59 AM, Paul Vriens  wrote:
> > Alexander Morozov wrote:
> > > > Can someone confirm that after running the devinst tests, the registry on
> > > > Wine still shows these:
> > > >
> > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> > > > stuff below)
> > > >
> > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> > > > below)
> > > >
> > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4
> > > > -3F65-11DB-B704-0011955C2BDB} (and stuff below)
> > >
> > > I can confirm this. Diff file with changes after running make devinst.ok is
> > > attached.
> >
> > Ok, so at least it looks we are compatible with Windows :-)
> >
> > I will check out your suggestion about using SetupDiRemoveDevice (and maybe
> > SetupDiRemoveDeviceInterface) to clean up the registry.
> >
> > I already found that it doesn't work on NT4 for everything as we have a bogus
> > bogus entry (missing the ClassGUID value). This means you can't even enumerate
> > this one and it won't be covered by the remove calls.
> >
> > So what about a cleanup_before function that gets rid of everything that's
> > currently bogus in the registry? If we don't do this before we have to cater for
> > existing keys in every test which will clutter the tests I think. If we really
> > want to test existing keys we should do so a part of a normal test.
> >
> > After that cleanup_before is working we can change the tests to clean up after
> > themselves.
>
> Will the new 'cleanup after' code not delete these invalid entries?
> One test run is fine to sacrifice for the sake of not cluttering up
> the tests with temporary cleanup code.

The problem is that we could have failures because of existing keys and we have 
to cater for that in every test maybe.

I agree with you though and will first check if having the 'cleanup after' 
serves it's purpose (even if we have to run the test twice to actually see results).

Could take a while though as I have to check which tests leaves what keys 
around. Then how I can get rid of them on every platform. Wine doesn't have the 
SetupDiRemove stuff yet btw.

[James Hawkins]

On Fri, May 23, 2008 at 3:10 AM, Paul Vriens  wrote:
> James Hawkins wrote:
> > On Fri, May 23, 2008 at 2:59 AM, Paul Vriens 
> > wrote:
> > > Alexander Morozov wrote:
> > > > > Can someone confirm that after running the devinst tests, the registry
> > > > > on
> > > > > Wine still shows these:
> > > > >
> > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> > > > > stuff below)
> > > > >
> > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> > > > > below)
> > > > >
> > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4
> > > > > -3F65-11DB-B704-0011955C2BDB} (and stuff below)
> > > >
> > > > I can confirm this. Diff file with changes after running make devinst.ok
> > > > is
> > > > attached.
> > >
> > > Ok, so at least it looks we are compatible with Windows :-)
> > >
> > > I will check out your suggestion about using SetupDiRemoveDevice (and
> > > maybe
> > > SetupDiRemoveDeviceInterface) to clean up the registry.
> > >
> > > I already found that it doesn't work on NT4 for everything as we have a
> > > bogus
> > > bogus entry (missing the ClassGUID value). This means you can't even
> > > enumerate
> > > this one and it won't be covered by the remove calls.
> > >
> > > So what about a cleanup_before function that gets rid of everything
> > > that's
> > > currently bogus in the registry? If we don't do this before we have to
> > > cater for
> > > existing keys in every test which will clutter the tests I think. If we
> > > really
> > > want to test existing keys we should do so a part of a normal test.
> > >
> > > After that cleanup_before is working we can change the tests to clean up
> > > after
> > > themselves.
> >
> > Will the new 'cleanup after' code not delete these invalid entries?
> > One test run is fine to sacrifice for the sake of not cluttering up
> > the tests with temporary cleanup code.
>
> The problem is that we could have failures because of existing keys and we
> have to cater for that in every test maybe.
>
> I agree with you though and will first check if having the 'cleanup after'
> serves it's purpose (even if we have to run the test twice to actually see
> results).
>
> Could take a while though as I have to check which tests leaves what keys
> around. Then how I can get rid of them on every platform. Wine doesn't have
> the SetupDiRemove stuff yet btw.

All I'm saying is that there shouldn't be a reason to have a hacky
pre-cleanup.  All the cleanup that is needed for the tests should be
added, and after one round of failures, the next set of tests should
be clean.

[Paul Vriens]

James Hawkins wrote:
> On Fri, May 23, 2008 at 3:10 AM, Paul Vriens  wrote:
> > James Hawkins wrote:
> > > On Fri, May 23, 2008 at 2:59 AM, Paul Vriens 
> > > wrote:
> > > > Alexander Morozov wrote:
> > > > > > Can someone confirm that after running the devinst tests, the registry
> > > > > > on
> > > > > > Wine still shows these:
> > > > > >
> > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> > > > > > stuff below)
> > > > > >
> > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> > > > > > below)
> > > > > >
> > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4
> > > > > > -3F65-11DB-B704-0011955C2BDB} (and stuff below)
> > > > >
> > > > > I can confirm this. Diff file with changes after running make devinst.ok
> > > > > is
> > > > > attached.
> > > >
> > > > Ok, so at least it looks we are compatible with Windows :-)
> > > >
> > > > I will check out your suggestion about using SetupDiRemoveDevice (and
> > > > maybe
> > > > SetupDiRemoveDeviceInterface) to clean up the registry.
> > > >
> > > > I already found that it doesn't work on NT4 for everything as we have a
> > > > bogus
> > > > bogus entry (missing the ClassGUID value). This means you can't even
> > > > enumerate
> > > > this one and it won't be covered by the remove calls.
> > > >
> > > > So what about a cleanup_before function that gets rid of everything
> > > > that's
> > > > currently bogus in the registry? If we don't do this before we have to
> > > > cater for
> > > > existing keys in every test which will clutter the tests I think. If we
> > > > really
> > > > want to test existing keys we should do so a part of a normal test.
> > > >
> > > > After that cleanup_before is working we can change the tests to clean up
> > > > after
> > > > themselves.
> > >
> > > Will the new 'cleanup after' code not delete these invalid entries?
> > > One test run is fine to sacrifice for the sake of not cluttering up
> > > the tests with temporary cleanup code.
> >
> > The problem is that we could have failures because of existing keys and we
> > have to cater for that in every test maybe.
> >
> > I agree with you though and will first check if having the 'cleanup after'
> > serves it's purpose (even if we have to run the test twice to actually see
> > results).
> >
> > Could take a while though as I have to check which tests leaves what keys
> > around. Then how I can get rid of them on every platform. Wine doesn't have
> > the SetupDiRemove stuff yet btw.
>
> All I'm saying is that there shouldn't be a reason to have a hacky
> pre-cleanup.  All the cleanup that is needed for the tests should be
> added, and after one round of failures, the next set of tests should
> be clean.

Agree

[Paul Vriens]

James Hawkins wrote:
> On Fri, May 23, 2008 at 3:10 AM, Paul Vriens  wrote:
> > James Hawkins wrote:
> > > On Fri, May 23, 2008 at 2:59 AM, Paul Vriens 
> > > wrote:
> > > > Alexander Morozov wrote:
> > > > > > Can someone confirm that after running the devinst tests, the registry
> > > > > > on
> > > > > > Wine still shows these:
> > > > > >
> > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> > > > > > stuff below)
> > > > > >
> > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> > > > > > below)
> > > > > >
> > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4
> > > > > > -3F65-11DB-B704-0011955C2BDB} (and stuff below)
> > > > >
> > > > > I can confirm this. Diff file with changes after running make devinst.ok
> > > > > is
> > > > > attached.
> > > >
> > > > Ok, so at least it looks we are compatible with Windows :-)
> > > >
> > > > I will check out your suggestion about using SetupDiRemoveDevice (and
> > > > maybe
> > > > SetupDiRemoveDeviceInterface) to clean up the registry.
> > > >
> > > > I already found that it doesn't work on NT4 for everything as we have a
> > > > bogus
> > > > bogus entry (missing the ClassGUID value). This means you can't even
> > > > enumerate
> > > > this one and it won't be covered by the remove calls.
> > > >
> > > > So what about a cleanup_before function that gets rid of everything
> > > > that's
> > > > currently bogus in the registry? If we don't do this before we have to
> > > > cater for
> > > > existing keys in every test which will clutter the tests I think. If we
> > > > really
> > > > want to test existing keys we should do so a part of a normal test.
> > > >
> > > > After that cleanup_before is working we can change the tests to clean up
> > > > after
> > > > themselves.
> > >
> > > Will the new 'cleanup after' code not delete these invalid entries?
> > > One test run is fine to sacrifice for the sake of not cluttering up
> > > the tests with temporary cleanup code.
> >
> > The problem is that we could have failures because of existing keys and we
> > have to cater for that in every test maybe.
> >
> > I agree with you though and will first check if having the 'cleanup after'
> > serves it's purpose (even if we have to run the test twice to actually see
> > results).
> >
> > Could take a while though as I have to check which tests leaves what keys
> > around. Then how I can get rid of them on every platform. Wine doesn't have
> > the SetupDiRemove stuff yet btw.
>
> All I'm saying is that there shouldn't be a reason to have a hacky
> pre-cleanup.  All the cleanup that is needed for the tests should be
> added, and after one round of failures, the next set of tests should
> be clean.

I just had a check for the testRegisterAndGetDetail test on Vista (dunno about 
the other tests and platforms yet).

I added the SetupDiRemoveDevice (as was suggested by Alexander) at the end of 
this test.

On a clean registry this works out fine (one DeviceClasses key is left but that 
one can be deleted without having to fiddle with permissions).

When I however first run the old tests (with leftovers in the registry) and then 
run the new test again the registry keys are still present.
When I do the SetupDiRemoveDevice twice at the end of testRegisterAndGetDetail 
the registry keys get deleted again (not that DeviceClasses key again).

So what would be a good approach? Just doing 2 SetupDiRemoveDevice's at the end 
to make sure old stuff is gone as well?
Or doing one, check if the Enum keys is still present and then do a second 
SetupDiRemoveDevice (with a trace message for clarity)?

[Alexander Morozov]

> I just had a check for the testRegisterAndGetDetail test on Vista (dunno
> about the other tests and platforms yet).
>
> I added the SetupDiRemoveDevice (as was suggested by Alexander) at the end
> of this test.
>
> On a clean registry this works out fine (one DeviceClasses key is left but
> that one can be deleted without having to fiddle with permissions).
>
> When I however first run the old tests (with leftovers in the registry) and
> then run the new test again the registry keys are still present.
> When I do the SetupDiRemoveDevice twice at the end of
> testRegisterAndGetDetail the registry keys get deleted again (not that
> DeviceClasses key again).
>
> So what would be a good approach? Just doing 2 SetupDiRemoveDevice's at the
> end to make sure old stuff is gone as well?
> Or doing one, check if the Enum keys is still present and then do a second
> SetupDiRemoveDevice (with a trace message for clarity)?

I think the second way is better.
May be a number of Enum keys is equal a quantity of doing old test?

[Paul Vriens]

Paul Vriens wrote:
> James Hawkins wrote:
> > On Fri, May 23, 2008 at 3:10 AM, Paul Vriens 
> >  wrote:
> > > James Hawkins wrote:
> > > > On Fri, May 23, 2008 at 2:59 AM, Paul Vriens 
> > > >
> > > > wrote:
> > > > > Alexander Morozov wrote:
> > > > > > > Can someone confirm that after running the devinst tests, the 
> > > > > > > registry
> > > > > > > on
> > > > > > > Wine still shows these:
> > > > > > >
> > > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS 
> > > > > > > (and
> > > > > > > stuff below)
> > > > > > >
> > > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and 
> > > > > > > stuff
> > > > > > > below)
> > > > > > >
> > > > > > >
> > > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses{6A55B5A4 
> > > > > > >
> > > > > > > -3F65-11DB-B704-0011955C2BDB} (and stuff below)
> > > > > > I can confirm this. Diff file with changes after running make 
> > > > > > devinst.ok
> > > > > > is
> > > > > > attached.
> > > > >
> > > > > Ok, so at least it looks we are compatible with Windows :-)
> > > > >
> > > > > I will check out your suggestion about using SetupDiRemoveDevice (and
> > > > > maybe
> > > > > SetupDiRemoveDeviceInterface) to clean up the registry.
> > > > >
> > > > > I already found that it doesn't work on NT4 for everything as we 
> > > > > have a
> > > > > bogus
> > > > > bogus entry (missing the ClassGUID value). This means you can't even
> > > > > enumerate
> > > > > this one and it won't be covered by the remove calls.
> > > > >
> > > > > So what about a cleanup_before function that gets rid of everything
> > > > > that's
> > > > > currently bogus in the registry? If we don't do this before we have to
> > > > > cater for
> > > > > existing keys in every test which will clutter the tests I think. 
> > > > > If we
> > > > > really
> > > > > want to test existing keys we should do so a part of a normal test.
> > > > >
> > > > > After that cleanup_before is working we can change the tests to 
> > > > > clean up
> > > > > after
> > > > > themselves.
> > > >
> > > > Will the new 'cleanup after' code not delete these invalid entries?
> > > > One test run is fine to sacrifice for the sake of not cluttering up
> > > > the tests with temporary cleanup code.
> > >
> > > The problem is that we could have failures because of existing keys 
> > > and we
> > > have to cater for that in every test maybe.
> > >
> > > I agree with you though and will first check if having the 'cleanup 
> > > after'
> > > serves it's purpose (even if we have to run the test twice to 
> > > actually see
> > > results).
> > >
> > > Could take a while though as I have to check which tests leaves what 
> > > keys
> > > around. Then how I can get rid of them on every platform. Wine 
> > > doesn't have
> > > the SetupDiRemove stuff yet btw.
> >
> > All I'm saying is that there shouldn't be a reason to have a hacky
> > pre-cleanup.  All the cleanup that is needed for the tests should be
> > added, and after one round of failures, the next set of tests should
> > be clean.
>
> I just had a check for the testRegisterAndGetDetail test on Vista (dunno 
> about the other tests and platforms yet).
>
> I added the SetupDiRemoveDevice (as was suggested by Alexander) at the 
> end of this test.
>
> On a clean registry this works out fine (one DeviceClasses key is left 
> but that one can be deleted without having to fiddle with permissions).
>
> When I however first run the old tests (with leftovers in the registry) 
> and then run the new test again the registry keys are still present.
> When I do the SetupDiRemoveDevice twice at the end of 
> testRegisterAndGetDetail the registry keys get deleted again (not that 
> DeviceClasses key again).
>
> So what would be a good approach? Just doing 2 SetupDiRemoveDevice's at 
> the end to make sure old stuff is gone as well?
> Or doing one, check if the Enum keys is still present and then do a 
> second SetupDiRemoveDevice (with a trace message for clarity)?

This is not going to be an easy thing.

Just did a test on W2K3 for the testRegisterDeviceInfo test.

On a clean registry (after a reboot) I can remove the device nicely right after 
the test. Doing the tests again though fails unless I reboot. So some 
information is stored somewhere (services.exe?).

When the tests are run a second time (without a reboot) the following key 
structure is created:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\BOGUS\0000\Control

After a reboot the Control key is gone. We can now just remove this by using 
SetupDiRemoveDevice.

So the scenarios:

After a reboot:

- clean registry
   - first tests will succeed and reg keys can be deleted afterwards
   - running the tests again will fail and create some regkeys that can't be 
deleted with SetupDiRemoveDevice in that same session (needs a reboot).
- USB\BOGUS\0000\Control is present
   - old tests have just been run and the system hasn't been rebooted since. Our 
new tests will fail.
- USB\BOGUS\0000 is present (but not the Control one)
   - we can remove the keys with SetupDiRemoveDevice
   - first tests will succeed and reg keys can be deleted afterwards
   - running the tests again will fail.

And this is just for W2K3, I haven't checked other OS's yet.

So on the one hand we can use this information to extends our tests. On the 
other hand it will mean a lot of checking and be prepared for different results. 
Different results in itself is not an issue of course as long as we know what's 
going on.