unknown device issues after running winetest
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) ? -- Cheers, Paul.
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. -- Cheers, Paul.
Hello Paul, 2008/5/20 Paul Vriens <paul.vriens.wine(a)gmail.com>:
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.
On Tue, May 20, 2008 at 8:17 PM, Juan Lang <juan.lang(a)gmail.com> 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. -- James Hawkins
James Hawkins wrote: > On Tue, May 20, 2008 at 8:17 PM, Juan Lang <juan.lang(a)gmail.com> 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? -- Cheers, Paul.
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. -- Cheers, Paul.
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? -- Cheers, Paul.
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
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: 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
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. -- Cheers, Paul.
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. -- Cheers, Paul.
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
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. -- Cheers, Paul.
Hello Juan, 2008/5/21 Juan Lang <juan.lang(a)gmail.com>:
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. My ipod patches (if they ever make it in) use them to register the ipod device.
Cheers, Maarten.
On Tue, May 20, 2008 at 8:08 PM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote:
Hello Paul,
2008/5/20 Paul Vriens <paul.vriens.wine(a)gmail.com>:
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
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. -- Cheers, Paul.
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 ...... -- Cheers, Paul.
В сообщении от 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.
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);
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. -- Cheers, Paul.
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. -- Cheers, Paul.
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.
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. -- Cheers, Paul.
On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> 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. -- James Hawkins
James Hawkins wrote:
On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> 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. -- Cheers, Paul.
On Fri, May 23, 2008 at 3:10 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote:
James Hawkins wrote:
On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> 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. -- James Hawkins
James Hawkins wrote:
On Fri, May 23, 2008 at 3:10 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote:
James Hawkins wrote:
On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> 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 -- Cheers, Paul.
James Hawkins wrote:
On Fri, May 23, 2008 at 3:10 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote:
James Hawkins wrote:
On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> 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)? -- Cheers, Paul.
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 wrote:
James Hawkins wrote:
On Fri, May 23, 2008 at 3:10 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote:
James Hawkins wrote:
On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> 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. -- Cheers, Paul.
participants (5)
-
Alexander Morozov -
James Hawkins -
Juan Lang -
Maarten Lankhorst -
Paul Vriens