This is what I think it may be:
12/22/12 10:31:41.000 AM kernel[0]: IOBluetoothUSBDFU::probe
12/22/12 10:31:41.000 AM kernel[0]: IOBluetoothUSBDFU::probe ProductID - 0x821F FirmwareVersion - 0x0097
12/22/12 10:31:41.000 AM kernel[0]: [BroadcomBluetoothHCIControllerUSBTransport][start] -- completed
12/22/12 10:31:41.000 AM kernel[0]: [IOBluetoothHCIController][staticBluetoothHCIControllerTransportShowsUp] -- Received Bluetooth Controller register service notification
12/22/12 10:31:41.000 AM kernel[0]: [IOBluetoothHCIController::setConfigState] calling registerService
12/22/12 10:31:41.000 AM kernel[0]: IOHIDDevice::newUserClient called on an inactive device
12/22/12 10:31:41.000 AM kernel[0]: IOHIDDevice::newUserClient called on an inactive device
12/22/12 10:31:41.564 AM blued[59]: kBTXPCUpdateUserPreferences gConsoleUserUID = 501
12/22/12 10:31:41.000 AM kernel[0]: IOHIDDevice::newUserClient called on an inactive device
12/22/12 10:31:41.000 AM kernel[0]: IOHIDDevice::newUserClient called on an inactive device
12/22/12 10:31:41.000 AM kernel[0]: IOHIDDevice::newUserClient called on an inactive device
12/22/12 10:31:41.000 AM kernel[0]: IOHIDDevice::newUserClient called on an inactive device
I don't have this Suunto movescount, I haven't run VMWare in a a few weeks, and there are no such services in the Activity Monitor.
Suspects: PS3 Controller driver, Xbox 360 Controller driver.
Quoted from the line of code referencing IOHIDDevice:
// RY: This is really skanky. Apparently there are some subclasses out there
// that want all the benefits of IOHIDDevice w/o supporting the default HID
// User Client. I know! Shocking! Anyway, passing a type known only to the
// default hid clients to ensure that at least connect to our correct client.
if ( type == kIOHIDLibUserClientConnectManager ) {
if ( isInactive() ) {
IOLog( "IOHIDDevice::newUserClient called on an inactive device\n" );
*handler = NULL;
return kIOReturnNotReady;