To blink multiple times per second, all the time. Just discovered that Broadcom Card Reader Service is causing hdd led See for example:Īfter knowing all this, the search for Broadcom Card Reader Service actually returns a few posts of people who discovered it earlier: on (I'm quoting the posts for which I haven't found s): A real notification (that is, quiet when there's nothing new happening) can be received by services via the SERVICE_CONTROL_DEVICEEVENT event. So I now know that Broadcom service programmers decided to poll for the _InstanceDeletionEvent of every logical disk every second and for _InstanceCreationEvent even 10 times per second! And they manage to involve COM, separate processes and do this over WMI/wmiprvse in a way that it's not observable (at least I haven't found out) that their service is doing this!Īnd there's proper solution for services and applications: RegisterDeviceNotification. ![]() This polling interval is specified by the WITHIN keyword and measured in seconds. Because the class being monitored does not have a corresponding event provider, the WMI polling mechanism is used to periodically check if an intrinsic event has occurred for the particular class. Note that the WITHIN clause specifies the polling interval for intrinsic event classes. Specifically, Microsoft documents how such constructs behave in the WMI: Observe the WITHIN clause in the queries. That is unbelievably bad programming of the service. Since the blinking happens so regularly, it's obvious that it is polling continuously. SELECT * FROM _InstanceCreationEvent WITHIN 0.1 WHERE TargetInstance ISA 'Win32_LogicalDisk' SELECT * FROM _InstanceDeletionEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_LogicalDisk' And as I'm actually a programmer, I've even inspected the strings inside of c:\Program Files\Broadcom\Memor圜ard\BrcmCardReader.exe and I've found what it exactly does, as soon as it's turned on: So finally one day after I've made an image backup of my whole system, I started with the brute force approach, turning off the things one by one, until the blinking stopped. But I knew that wmiprvse isn't doing it on itself, I knew there must be some other process commanding. This inability to see who actually commands the activity is also the explanation why some people here claim that "it's an operating system:" whoever stops at this point doesn't see anything else. So at that moment I wasn't able to discover that Broadcom Card Reader Service does it as nothing logged pointed to it, that's why I'm quoting all this in order to ease the pain for anybody who puts these items in the search machine. Microsoft obviously does poor job in this trace: the CIMWin32, the host id, the provider guid and the path all point to the binary executing the WMI, not to the program making WMI queries. ProviderInfo for GroupOperationId = 101 Operation = Provider::CreateInstanceEnum - CIMWin32 : Win32_LogicalDisk HostID = 2368 ProviderName = CIMWin32 ProviderGuid = Path = %systemroot%\system32\wbem\cimwin32.dll It wasn't useful, I was able to observe only As I knew that wmiprvse is actually a WMI execution component written by Microsoft I even tried using Event Log to trace the WMI activity, as documented on MSDN. ![]() I've first tried to figure out what causes the blinks only to find that it was something like wbem wmiprvse.exe that did things like IRP_MJ_QUERY_INFORMATION and IRP_MJ_QUERY_VOLUME_INFORMATION for every drive. But this service written by Broadcom is another story. Contrary to what's written in the other posts here, the operating system itself isn't so badly written to poll anything. And of course I didn't have to disable the CD-ROM or cover the LED with the tape to achieve this. As soon as I've stopped the service the blinking stopped too. The real culprit of HDD LED blinking on my Acer notebook was the service internally named BrcmCardReader with the long name Broadcom Card Reader Service.
0 Comments
Leave a Reply. |