unknown device issues after running winetest

[Paul Vriens]

Paul Vriens wrote:
> James Hawkins wrote:
>> On Fri, May 23, 2008 at 3:10 AM, Paul Vriens 
>> <paul.vriens.wine at gmail.com> wrote:
>>> James Hawkins wrote:
>>>> On Fri, May 23, 2008 at 2:59 AM, Paul Vriens 
>>>> <paul.vriens.wine at 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.