March 2011


One of the things on my to-do list for our Widcomm support is that on some of the device platforms once the device has gone through a power-down-up change the stack needs to be restarted. On my Asus device in this case we find that some operations fail. Once we re-create the Widcomm objects they works again.

What fails when

On my older iPAQ with Widcomm version after a power-down-up, there is no problem: things works ok.

On my Asus with Widcomm version “1.8.0 build 4800”, the stack needs to be reset. If we don’t restart the stack then Device Discovery (CBtIf::StartInquiry) and Service Discovery (StartDiscovery) fail for instance (and the latter affects BtCli.Connect).

What we tried

So the obvious thing to do in this case is to close the existing Widcomm C++ objects and initialise new ones. So I implemented that: when the Stack-Down event has been seen, the next time we do an operation we dispose our instance of the CBtIf object and ‘new’ a new instance.

What works and doesn’t

On the Asus that works fine, StartInquiry etc work successfully after the dispose/re-create.

On the iPAQ that’s the case also, but only if we leave some time after the restart before using the stack again. Instead if we access the new instance too soon after the restart we get a crash. Well it looks like a crash in that the application just disappears, but it doesn’t look like a crash in that we get no crash dialog nor apparently any crash dump. Why not?? And we can inspect it with the debugger as we can’t have a debugger stay attached over the power-down-up and it takes too long for ActiveSync and/or a debugger to re-attach to be able to catch the crash.

Any suggestions about investigating this crash are welcomed…

Other thoughts

The other thought was to check the IsStackServerUp and IsDeviceReady methods provided by the Widcomm CBtIf class. We would check these and delay things until the stack was in a safe state. However these methods were added in a version after that that the problematic device has, they were added in but the iPAQ has  So they’re not available on the very platform that we need them on.

I had hoped anyway that closing the instance and creating a new one would make everything right — internally it would do a wait if necessary.  What we see of course that the new instance is returned, but then something unknown fails…


One begins to consider whether we need to add some some of version check hack: if (version < 1.8.0.xxxx) then delay-new-instance-creation.  Or something like that…

Or, looking at the logs maybe we can maybe use the different events produced to fingerprint the version.

iPAQ log
At 15:50:20: StackStatusChange: Unloaded
At 15:50:27: StackStatusChange: Reloaded

Asus log
At 15:52:44: StackStatusChange: Down
At 15:53:11: StackStatusChange: Unloaded

Note the difference: iPAQ: Unloaded+Reloaded, Asus: Down+Unloaded with no Reloaded.

Out of interest: Firstly, why no Reloaded in the latter case?  Because the stack is detached on that platform??  Secondly the Widcomm docs say: “DEVST_DOWN indicates that the Bluetooth stack server has been shut down and is not expected to be restarted.”, but that’s not the case here.  Hmm, they seem a bit confused… 🙂

I think we’ll have a think about using the Down+Unloaded case to find that the platform needs reset and don’t do the reset in the other cases.  I’ll try and test this on other devices and see what I find.

Other thoughts welcome…


A page from the BlueCove Java Bluetooth library documentation showing how to identify which Bluetooth stack is installed It shows screenshots of the device driver info on Windows XP for the Microsoft, Widcomm, and BlueSoleil stacks.