MacBidouille

Il y a eu plusieurs hypothèses qui ont été relayées y-compris ici-même et par votre serviteur, dont une erreur dans les règles ou patterns de détection de virus, qui auraient alors mis en quarantaine des fichiers indispensables à Windows.

Cela ne collait pas avec le fix rapide consistant à éliminer un fichier .sys, puisqu'il aurait alors fallu aussi ramener le ou les fichiers en quarantaine dans leurs emplacements d'origine.
Ça aurait du attirer mon attention. Mais les informations reçues étaient contradictoires.

Grâce à Zach Vorhies on a une piste très crédible.
Non un "Null Pointer" (Pointeur nul valant 0) comme il l'indique, pas un "null pointer derefence" (déréférencement mémoire d'un pointeur valant 0), mais une lecture indirecte de la page 0 via un pointeur non-null (à l'adresse 0x9c précisément).

La page 0 est protégée des accès en lecture et en écriture par le Kernel de Window justement pour provoquer une exception lors de ceux-ci car c'est une erreur courante en assembleur, en C et dans tous les langages où le programmeur gère lui-même les pointeurs via son code.
On ne peut pas protéger matériellement uniquement l'adresse 0, c'est donc toute la page qui est protégée.
L'accès à cette page, que ça soit en lecture ou en écriture, déclenche une Exception de type Violation d'Accès, et généralement l'arrêt du programme si en mode utilisateur.
En mode Kernel, comme c'est le cas ici, cette Exception déclenche le crash du Kernel et donc de Windows!

C'est le jeu de données utilisé "Channel 291" du produit Sensor de CrowdStrike, destiné aux versions sous Windows 7.11 et suivant qui a généré une erreur de logique, expliquant que le problème ne se produise pas sous macOS ou Linux.

Les cause-racines sont une non-validation des données lues par le code (un grand classique), d'avoir poussé une MàJ non validée, d'avoir mis des données corrompues dans une MàJ, et de ne pas avoir procédé à des tests corrects.
CrowdStrike va vraiment avoir des réponses à apporter...