A bug in Location&Sensor framework runtime in Windows 7 (SensorAPI.dll)

[kasya-82]

I want to report a bug found in Location&Sensor framework runtime in
Windows 7 (SensorAPI.dll).
Under some circumstances our application is faulting with the
following exception after deinitializing COM library:

Faulting application name: SensorApiTest.exe, version: 1.0.0.0, time
stamp: 0x4cb59a64
Faulting module name: SensorsApi.dll_unloaded, version: 0.0.0.0, time
stamp: 0x4a5be06d
Exception code: 0xc0000005
Fault offset: 0x000007fef86ca541
Faulting process id: 0x16f8
Faulting application start time: 0x01cb6ad2ff305600
Faulting application path: C:\Tests\SensorApiTest.exe
Faulting module path: SensorsApi.dll
Report Id: 780a09e6-d6c6-11df-806b-e0cb4e291545

Minimal code to reproduce on Windows 7 (x32 and x64):

#include <windows.h>
#include <atlbase.h>
#include <sensors.h>
#include <sensorsapi.h>

void findSensor()
{
CComPtr<ISensorManager> pSensorManager;

HRESULT hr = pSensorManager.CoCreateInstance(CLSID_SensorManager);
if (FAILED(hr))
{
printf("unable to retrieve sensor manager object (%u)", hr);
return;
}

CComPtr<ISensorCollection> pSensorColl;

hr = pSensorManager-
>GetSensorsByType(SENSOR_TYPE_ACCELEROMETER_3D, &pSensorColl);
}

int _tmain(int argc, _TCHAR* argv[])
{
for (int i = 0; i < 40000; ++i)
{
CoInitializeEx(NULL, COINIT_MULTITHREADED);
findSensor();
CoUninitialize();
printf("%i\n", i);
}

return 0;
}

The reason seems to be incorrect internal deinitialization of Sensor
API. After a call to ISensorManager::GetSensorsByType() we see several
internal worker threads created, and those keep running even after we
release the interfaces (ISensorManager and ISensorCollection) and call
CoUninitialize() which results in SensorsApi.dll being unloaded.
Probably later those threads awake and try to execute code that is
already unmapped from the process.
In our tests we mostly see the crash reproduced between iteration 1000
and 2000.

If we call CoInitializeEx()/CoUninitialize() only once (at the
beginning and at the end of application lifecycle) the problem is not
reproduced. Unfortuantely we can't do that in our code since it is a
reusable component which may be created once or many times, and should
always free all resources gracefully after being destroyed. It is
inappropriate for us to have our component spawn worker threads (from
SensorsApi.dll) that remain forever in the calling application, with a
risk to cause a crash.