Quando o hardware está falhando, pode causar vários sintomas. O mais provável é uma Tela Azul da Morte, mas sintomas menores podem aparecer com a mesma facilidade. Para ter uma ideia melhor de como os programas aparentemente não relacionados podem ser afetados pelo hardware, considere o modelo do sistema operacional:
Software do usuário > Kernel > Camada de abstração de hardware > Hardware
Qualquer programa que queira interagir literalmente com qualquer recurso, até mesmo a CPU ou RAM, tem que cooperar com o kernel, que por sua vez depende da HAL para traduzir os vários sinais físicos de e para o hardware em sinais lógicos e do kernel.
O kernel tem certas restrições para garantir a estabilidade, como a capacidade limitada de ser reentrante, a segurança de threads, limitações de recursos e assim por diante. Particularmente, a maioria dos hardwares não tem o conceito de ser compartilhado; isso é abstraído em um nível mais alto por meio dos drivers HAL ou kernel.
Se você se lembrar dos dias de modems, somente um programa por vez poderia usar o modem, como o discador. A Internet contornou isso produzindo uma pilha comum - todos os programas que desejavam acessar a Internet o fizeram por meio de uma pilha comum, e essa pilha tinha controle exclusivo do hardware. A pilha produziu multiplexação para compartilhar esse recurso.
Ainda hoje, as placas de som, as unidades de disco, as placas de vídeo e assim por diante não podem ser compartilhadas fisicamente. Os sinais ficariam confusos e o caos ocorreria. O HAL faz um bom trabalho ao enganar os usuários, fazendo-os pensar que há mais de uma coisa acontecendo de cada vez. Ainda existe um gargalo físico, mas normalmente não percebemos quando o hardware está funcionando da maneira pretendida.
Mas, para chegar ao núcleo do problema, se o HAL tiver um problema de comunicação com um dispositivo, ele poderá ficar bloqueado enquanto tenta reenviar ou reler os dados repetidas vezes. O HAL também não é normalmente multithreaded, portanto, ele só pode manipular um pedido por vez (por cadeia de driver).
Se o driver de disco estiver bloqueado, tente ler uma unidade defeituosa, por exemplo, qualquer outro programa que tente fazer uma chamada de API semelhante estará na fila atrás da chamada bloqueada, resultando na suspensão desse programa. Programas multi-threaded não teriam esse problema, porque a interface do usuário poderia permanecer responsiva enquanto a unidade estava bloqueada. Infelizmente, a maioria dos programas não é
Muitos programas no Windows basicamente entram em um loop, como este:
while(GetMessage(&msg, hWnd, NULL, NULL)) {
DispatchMessage(&msg);
}
Como você pode imaginar, há apenas um segmento. Uma vez que ele tenta ler de uma unidade que está pendurada, ela não pode se recuperar até que a unidade chegue ao tempo limite. Se não, esse programa está à mercê da API do sistema operacional. Mesmo se fosse multi-threaded, no entanto, o segmento de leitura de unidade seria bloqueado, embora o segmento de interface do usuário seria capaz de detectar isso e recuperar / abortar.
Para compor o problema, muitas chamadas de API, como aquelas que alocam memória, unidades ou arquivos abertos, etc, são todas chamadas de bloqueio . Eles fazem com que o segmento atual espere indefinidamente (a menos que solicite um valor de tempo limite específico) até que o sistema operacional possa concluir a solicitação ou abortar devido a um tempo limite. A maioria dos programas não assume que o sistema operacional demore muito e, portanto, nunca especifique um tempo limite. Esses programas nunca serão recuperados se a unidade não responder.
Para um programa que "nunca acessa a unidade com falha", isso não é necessariamente necessário. Tudo o que precisa fazer é chamar uma função atualmente bloqueada pela unidade defeituosa. Por exemplo, se o OpenFile tiver sido chamado na unidade de DVD incorreta, outras solicitações de arquivo poderão ficar suspensas até que a unidade de DVD expire, mesmo que estejam apenas lendo da unidade do sistema.
Talvez o programa chame GetOpenFileName, que mostra uma caixa de diálogo renderizada pelo SO que assume o controle do encadeamento até retornar. Essa janela lista todas as unidades no sistema, enumerando a lista de unidades. Se a API estiver suspensa em uma unidade defeituosa, o resultado final é o mesmo: a caixa de diálogo está congelada, congelando todo o aplicativo, aguardando que essa unidade fique disponível / livre.