Ho dato uno sguardo ora, una decina di minuti (e altri 20 per scrivere
deformazione professionale...).
Analisi dei crashdumps
File 091324-7000-01.dmp
Un pò di dati incomprensibili prima, per dare il quadro.
L'errore che hai visto nella schermata blu è DRIVER_IRQL_NOT_LESS_OR_EQUAL.
Codice:
rax=0000000000000000 rbx=0000000000000000 rcx=fffff80308605f38
rdx=ffff99832d7f0010 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8030f04c4e4 rsp=fffff80308605dc0 rbp=fffff80308605e39
r8=ffff99832d7f0010 r9=0000000000000b58 r10=ffff998331a05210
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
NETIO!StreamInvokeCalloutAndNormalizeAction+0x5c:
fffff803`0f04c4e4 488b4808 mov rcx,qword ptr [rax+8] ds:00000000`00000008=????????????????
Il problema è causato da RAX, che non è valido (null pointer, tecnicamente) che provoca come indirizzo RAX (che vale 0) + 8. Locazione di memoria non valida.
Il processo in esecuzione è coerente con quanto dicevi sopra, si tratta di
chrome.exe.
Purtroppo la funzione nella quale avviene il crash
StreamInvokeCalloutAndNormalizeAction
non è pubblica, quindi non si capisce nemmeno se il problema è da qualche altra parte o al suo interno; risalire solo dal codice che vedo è lungo + non so dove porta in quanto mancheranno informazioni nel crash dump.
Esempio:
Codice:
NETIO!StreamInvokeCalloutAndNormalizeAction:
fffff803`0f04c488 488bc4 mov rax, rsp
fffff803`0f04c48b 48895808 mov qword ptr [rax+8], rbx
fffff803`0f04c48f 48897018 mov qword ptr [rax+18h], rsi
fffff803`0f04c493 48897820 mov qword ptr [rax+20h], rdi
fffff803`0f04c497 48895010 mov qword ptr [rax+10h], rdx
fffff803`0f04c49b 55 push rbp
fffff803`0f04c49c 4154 push r12
fffff803`0f04c49e 4155 push r13
fffff803`0f04c4a0 4156 push r14
fffff803`0f04c4a2 4157 push r15
fffff803`0f04c4a4 488d68b1 lea rbp, [rax-4Fh]
fffff803`0f04c4a8 4881eca0000000 sub rsp, 0A0h
fffff803`0f04c4af 4d8b5010 mov r10, qword ptr [r8+10h]
fffff803`0f04c4b3 4533db xor r11d, r11d
fffff803`0f04c4b6 488b7577 mov rsi, qword ptr [rbp+77h]
fffff803`0f04c4ba 33c0 xor eax, eax
fffff803`0f04c4bc 488945d7 mov qword ptr [rbp-29h], rax
fffff803`0f04c4c0 0f57c0 xorps xmm0, xmm0
fffff803`0f04c4c3 0f1145c7 movups xmmword ptr [rbp-39h], xmm0
fffff803`0f04c4c7 498b8288000000 mov rax, qword ptr [r10+88h]
fffff803`0f04c4ce 4d8be9 mov r13, r9
fffff803`0f04c4d1 4d8b8a90000000 mov r9, qword ptr [r10+90h]
fffff803`0f04c4d8 488bd9 mov rbx, rcx
fffff803`0f04c4db 498bf8 mov rdi, r8
fffff803`0f04c4de 458afb mov r15b, r11b
fffff803`0f04c4e1 458ae3 mov r12b, r11b
fffff803`0f04c4e4 488b4808 mov rcx, qword ptr [rax+8]
il crash avviene sull'ultima istruzione (riga). Risalendo si vede che il valore in RAX viene spostato da R10+88h, che a sua volta arriva da R8+10h.
Sicuramente R10 e R8 contengono una qualche struttura dati; R8 è un registro usato per il passaggio dei parametri a una funzione, quindi chi chiama questa funzione ha inserito un valore (che a vista, guardando i registri sopra, è buono).
Ergo mi fermo qui.
Passiamo al successivo.
File 091524-8109-01.dmp
Codice:
0: kd> .trap 0xfffff8024a265f10
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffb108ba0bb201 rbx=0000000000000000 rcx=00000000ffffff00
rdx=0000000000001001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80250cac6c1 rsp=fffff8024a2660a0 rbp=fffff8024a266119
r8=0000000000001001 r9=0000000000000000 r10=000000000001057f
r11=0000000000000108 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
NETIO!StreamInvokeCalloutAndNormalizeAction+0x239:
fffff802`50cac6c1 4183795003 cmp dword ptr [r9+50h],3 ds:00000000`00000050=????????
Analogo al caso precedente, cambia però l'istruzione, non siamo nel solito posto; ma qui il registro che contiene il famoso null pointer è R9, non più RAX. E' anche molto più sotto nel codice, seppur la funzione sia la medesima.
La cosa interessante però è il contesto nel quale ci si trova: il processo che ha causato il crash non è più Chrome ma
logi_lamparray.
Domande / considerazioni
Dal nome già pare evidente sia di Logitech.
E qui ti chiedo:
- guarda i servizi (premi WIN + R e digita services.msc): probabilmente hai un servizio chiamato "Logitech LampArray service"
- hai prodotti logitech, come un mouse per esempio o qualche altra cosa logitech collegata al pc?
Trovata la periferica vai sul sito del produttore e guarda se ci sono driver nuovi. Se non ce ne sono dovresti provare ad arrestare quel servizio e a stopparlo. Non so cosa regola a essere sincero, ma dubito sia qualcosa di davvero vitale, nel caso per esempio del mouse.
Ho il sospetto non troppo vago che si verifichi qualcosa (race condition o qualsiasi altra cosa poco piacevole) dovuto a un bug del driver che causi poi il crash all'interno di quel driver (NETIO.sys). Magari è un errore del driver stesso, magari è dovuto a quello di Microsoft... who knows. Più probabile sia il driver (di terze parti) a fare qualche casotto, tra i due.