O verdadeiro culpado do LED HDD piscando no meu notebook Acer foi o serviço internamente chamado BrcmCardReader com o nome longo Broadcom Card Reader Service. Assim que parei o serviço, o piscar também parou. E é claro que não precisei desativar o CD-ROM ou cobrir o LED com a fita para conseguir isso. Ao contrário do que está escrito nas outras postagens aqui, o próprio sistema operacional não está tão mal escrito para pesquisar qualquer coisa. Mas este serviço escrito pela Broadcom é outra história.
Primeiro tentei descobrir o que causa o piscar, apenas para descobrir que era algo como o wbem wmiprvse.exe que fazia coisas como IRP_MJ_QUERY_INFORMATION
e IRP_MJ_QUERY_VOLUME_INFORMATION
para cada unidade. Como eu sabia que o wmiprvse é realmente um componente de execução WMI escrito pela Microsoft, tentei usar o Log de Eventos para rastrear a atividade WMI, conforme documentado no MSDN. Não foi útil, eu era capaz de observar apenas
ProviderInfo for GroupOperationId = 101; Operation = Provider::CreateInstanceEnum - CIMWin32 : Win32_LogicalDisk; HostID = 2368; ProviderName = CIMWin32; ProviderGuid = {d63a5850-8f16-11cf-9f47-00aa00bf345c}; Path = %systemroot%\system32\wbem\cimwin32.dll
A Microsoft obviamente faz um trabalho ruim nesse rastreamento: o CIMWin32, o ID do host, o guia do provedor e o caminho apontam para o binário executando o WMI, não para o programa que faz consultas WMI. Portanto, naquele momento, não consegui descobrir que o Broadcom Card Reader Service faz isso como nada registrado apontou para ele, é por isso que estou citando tudo isso para aliviar a dor de quem coloca esses itens na máquina de busca. Essa incapacidade de ver quem realmente comanda a atividade também é a explicação por que algumas pessoas aqui afirmam que "é um sistema operacional:" quem parar neste momento não vê mais nada. Mas eu sabia que o wmiprvse não está fazendo isso por si só, sabia que devia haver algum outro processo de comando.
Então, finalmente, um dia depois de fazer um backup de imagem de todo o sistema, comecei com a abordagem de força bruta, desligando as coisas uma a uma, até que o piscar parasse. Então agora eu tenho certeza. É o serviço Broadcom Card Reader . E, como sou programador, inspecionei as cadeias c:\Program Files\Broadcom\MemoryCard\BrcmCardReader.exe
e descobri o que exatamente faz, assim que é ativado:
SELECT * FROM __InstanceDeletionEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_LogicalDisk'
SELECT * FROM __InstanceCreationEvent WITHIN 0.1 WHERE TargetInstance ISA 'Win32_LogicalDisk'
Como o piscar acontece com tanta regularidade, é óbvio que ele está pesquisando continuamente. Isso é incrivelmente ruim de programação do serviço. Observe a cláusula WITHIN nas consultas. Especificamente, a Microsoft documenta como essas construções se comportam no WMI:
http://technet.microsoft.com/en-us/magazine/2006.09.wmievents.aspx
Observe que a cláusula WITHIN especifica o intervalo de pesquisa para classes de eventos intrínsecos. Como a classe que está sendo monitorada não possui um provedor de eventos correspondente, o mecanismo de pesquisa WMI é usado para verificar periodicamente se ocorreu um evento intrínseco para a classe específica. Esse intervalo de pesquisa é especificado pela palavra-chave WITHIN e medido em segundos.
Então, agora eu sei que os programadores de serviços Broadcom decidiu poll para o __InstanceDeletionEvent
de cada disco lógico cada segundo e de __InstanceCreationEvent
até 10 vezes por segundo ! E eles conseguem envolver COM, separar processos e fazer isso através de WMI / wmiprvse de uma maneira que não é observável (pelo menos eu não descobri) que o serviço deles esteja fazendo isso!
Programação ruim, incrivelmente ruim.
E não há solução adequada para serviços e aplicações: RegisterDeviceNotification
. Uma notificação real (ou seja, silenciosa quando não há nada de novo acontecendo) pode ser recebida pelos serviços através do SERVICE_CONTROL_DEVICEEVENT
evento. Veja por exemplo:
/programming/706352/use-registerdevicenotification-for-all-usb-devices
Depois de saber tudo isso, a pesquisa pelo Broadcom Card Reader Service na verdade retorna algumas postagens de pessoas que o descobriram anteriormente: em community.acer.com (estou citando as postagens para as quais não encontrei permalinks):
"Vladan Re: Aspire 5750Z driver do leitor de cartão, Win 8 29-11-2012 06:29
Acabei de descobrir que o Broadcom Card Reader Service está fazendo com que o HDD pisque várias vezes por segundo, o tempo todo. A interrupção e configuração deste serviço como manual ou mesmo desativado corrigem o problema de piscar sem afetar a funcionalidade do leitor de cartão ".
no bleepingcomputer.com:
"Cheesenbranston Postado 28 de maio de 2013 - 04:47
Eu tive um problema semelhante desde a instalação do Win8 pro x64 como uma nova instalação, ou seja, não como uma atualização. No Gerenciador de tarefas, embora a taxa de transferência do disco não parecesse, o uso particularmente alto era constantemente de 100%. Acredito que identifiquei o problema como sendo o serviço Broadcom Card Reader. "
e na Amazon.co.uk, uma revisão por SJ Harvey em 1 de fevereiro de 2013:
http://www.amazon.co.uk/review/R3GZB5OXP4SNP7/ref=cm_cr_rdp_perm?ie=UTF8&ASIN=B009QZCYU4&linkCode=&nodeID=&tag=
A única coisa que REALMENTE me incomodou (observe o pretérito) é que a luz da unidade piscava constantemente. Não era atividade de HDD e, depois de algumas horas, localizei o culpado. Era o serviço Broadcom Card-Reader .
Ele ainda sugere mudar o serviço para manual, no meu computador eu tive que desativá-lo completamente.
Assim, as pessoas até relataram maior uso de recursos, além de apenas o LED do disco rígido piscar.
A solução final: desative o " Broadcom Card Reader Service " : em Serviços, vá para suas propriedades, pare-o e altere seu tipo de inicialização para "desativado". O piscar finalmente vai parar. Eu realmente gostaria de saber qual é o objetivo disso de qualquer maneira - o que estou perdendo ao desativá-lo? Vendo quão mal está programado, não ficaria surpreso que todo o objetivo do serviço seja alterar algum ícone quando o cartão de memória estiver inserido! O que tenho certeza é que o mau uso do WMI é uma péssima programação.