[MDA III, XDA III, PDA2k, 9090 General] Etter:
If your Bluetooth is staying connected but disconnecting during the resuming state or when you turn it on with the power button. Then it sounds like you have an issue with ResetOnResume. Certain drivers unload then reload the instant they come out of the suspence state. And if they are entering a scheduled resuming state then they may be unloading and either don't have time or don't see a need to reload before they go back into suspence.

Have you guys messed with:

HKLM\comm\asyncmac1\parms\RebindOnResume

HKLM\comm\asyncmac1\parms\DisablePowerManager

Maybe if you enabled the powermanager then you could control certain device states using D0, D1, D2 or D3. If it's diasabled then D0 shouldn't mean anything to the driver.

Also:

HKLM\comm\tiacxwln1\parms\ResetOnResume should turn on your wifi when reset.

I have a question in the middle of my sharing. Which is the physical radio that transmits Bluetooth? Is it AsyncMac or tiacxwln? One of these may be unloading which is forcing the Bluetooth stack to unload.

Another thing:

Also go through HKLM\Drivers\Active. Note every driver and look where they are loaded from, most of them are loaded from HKLM\Driver\BuiltIn\XXXX. If they have a key named IClass and it is one of the power management classes then you can control it with the device states. In my registry the only devices that are defined by a power manageable IClass are BTS and NDS. And they are registered to the generic IClass {A32.... But in HKLM\...\Power\State\Suspend\ there is an iclass of {98... (NDIS). Who cares is you put NDS0: D0 in there if it is still being told what to do by the generic IClass.

So what's up with that? The NDIS devices may be controled by two different pawer management classes. Which is legal as stated on MSDN. And it is also legal to define an IClass inside the driver, unseen in the registry. So if you set Power\State\Suspend\{98.....}\NDS0:dword="d0" the NDS0: driver may still be getting device state settings from the Generic {A32.....} IClass.

You can try deleting the iclass keys from HKLM\Driver\BuiltIn\XXXX and reboot. That may release it froam that class, but who knows what other PM classes they are assigned to inside the driver. I have seen {98C5250D-C29A-4985-AE5F-AFE5367E5006}\TIACXWLN1 popup right in HKLM\sys\...\Power\States\ So right there you can see the driver is messing with PM even though it didn't tell you earlier.

The NDIS Driver is supposed to control ALL the other devices in the NDIS group. So it may be unessissary to set something like AGW1: to D0 since it's being flipped on and off by NDS0: (I think). And if that driver is not written to know what D0 is, then what's the point? You can assign my big toe to the power manageable block devices IClass but it will react the same way as if you assigned a driver that didn't know what was going on.

AsyncMac and tiacxwln are device drivers that control the physical radio. I don't know which is which.

The last thing I need to note. I can't find the text now, but the arcitecture for either the bluetooth or the power manager is the same between WM5 and WM2003SE. So when you are searching through MSDM don't forget to read stuff that say "Windows CE 4.2 and later"

Sorry about the rant. I just wanted to bring this up and see if people have been messing with these settings. And sorry it was so long.