Probleme hardware

[Boggy]

Chiar si cu aia 150mb/s ar trebui sa simti un upgrade mare in real life, timpul de acces face o diferenta enorma.

[agarici cu pedale]

Care ma poti ajuta cu un mister dintr-un dump, nu reusesc sa-i dau de cap sub nici o forma, cand esti prost esti prost pana la capat.

https://1drv.ms/u/s!As_Zx7Eh7JgSo3URk_uREYpbwNYT

Am bsod cu urmatoarlee
INVALID_WORK_QUEUE_ITEM 0x00000096
Parametrii
ffffb28c`63352ce0
fffff800`c3284650
fffff800`c3284380
fffff800`c2eaad90
ntoskrnl.exe
ntoskrnl.exe+16c3f0

Chiar ma depaseste fiindca nu gasesc ceva exact.

LE: Momentan am dat jos Soundblaster SE-ul ca tind sa cred ca el e vinovatul.
Problema principala se manifesta in felul urmator, cand eram pe skype imi crapa skype-ul in conferinta doar si nu mai puteam sa-l folosesc pana nu dadeam restat pe partea de call, doar text altfel freezuia aplicatia.
Reinstall OS ca deja ma disperat fiindca nu gasisem fix.

Azi toate bune si frumoase, skype merge bine, intru intr-un joc si freeze la pc pe sunet repetitiv si apoi bsod, de 2 ori la rand la fel, ambele in combinatie cu call pe skype la activ.
Umtorul pas e sa schimb si cablul SATA la SSD.

[kobro]

bluescreenview ce zice?

[agarici cu pedale]

SPOILER:

Loading Dump File [C:\Users\Cosy\AppData\Roaming\Skype\My Skype Received Files\062117-13703-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 15063 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 15063.0.amd64fre.rs2_release.170317-1834
Machine Name:
Kernel base = 0xfffff800`c2e8c000 PsLoadedModuleList = 0xfffff800`c31d85a0
Debug session time: Wed Jun 21 13:33:54.224 2017 (UTC + 3:00)
System Uptime: 0 days 0:22:28.860
Loading Kernel Symbols
.................................................. .............
.................................................. ..............
.................................................. ..............

Loading User Symbols
Loading unloaded module list
........
************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************

Use !analyze -v to get detailed debugging information.

BugCheck 96, {ffffb28c63352ce0, fffff800c3284650, fffff800c3284380, fffff800c2eaad90}

Probably caused by : ntkrnlmp.exe ( nt!IopProcessWorkItem+0 )

Followup: MachineOwner
---------

4: kd> !analyze -v
************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************

INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null. This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this. The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: ffffb28c63352ce0, The address of the queue entry whose flink/blink field is NULL
Arg2: fffff800c3284650, The address of the queue being references. Usually this is one
of the ExWorkerQueues.
Arg3: fffff800c3284380, The base address of the ExWorkerQueue array. This will help determine
if the queue in question is an ExWorkerQueue and if so, the offset from
this parameter will isolate the queue.
Arg4: fffff800c2eaad90, If this is an ExWorkerQueue (which it usually is), this is the address
of the worker routine that would have been called if the work item was
valid. This can be used to isolate the driver that is misusing the work
queue.

Debugging Details:
------------------


WORKER_ROUTINE:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

FAULTING_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

WORK_ITEM: ffffb28c63352ce0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x96

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff800c304bdbc to fffff800c2ff83f0

STACK_TEXT:
ffff8b80`621c6ac8 fffff800`c304bdbc : 00000000`00000096 ffffb28c`63352ce0 fffff800`c3284650 fffff800`c3284380 : nt!KeBugCheckEx
ffff8b80`621c6ad0 fffff800`c2eca00e : 00000000`00000000 00000000`00000000 fffff800`c3284650 ffffb28c`6c65e040 : nt!KiAttemptFastRemovePriQueue+0xc929c
ffff8b80`621c6b10 fffff800`c2ec9c50 : 00000000`00000100 ffffb28c`6c65e000 fffff800`c2eaad90 00000000`0000000c : nt!KeRemovePriQueue+0x19e
ffff8b80`621c6b80 fffff800`c2f68a37 : ffffb28c`65772cc0 00000000`00000080 ffffb28c`5ea7d040 ffffb28c`6c65e040 : nt!ExpWorkerThread+0x80
ffff8b80`621c6c10 fffff800`c2ffd876 : ffff8b80`1abde180 ffffb28c`6c65e040 fffff800`c2f689f0 ffff813c`029eaa01 : nt!PspSystemThreadStartup+0x47
ffff8b80`621c6c60 00000000`00000000 : ffff8b80`621c7000 ffff8b80`621c1000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

SYMBOL_NAME: nt!IopProcessWorkItem+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 59327910

IMAGE_VERSION: 10.0.15063.413

BUCKET_ID_FUNC_OFFSET: 0

FAILURE_BUCKET_ID: 0x96_nt!IopProcessWorkItem

BUCKET_ID: 0x96_nt!IopProcessWorkItem

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x96_nt!iopprocessworkitem

FAILURE_ID_HASH: {9b586d9a-c1f6-a6de-4692-9ceab4008b6f}

Followup: MachineOwner
---------

4: kd> !analyze -v
************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************

INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null. This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this. The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: ffffb28c63352ce0, The address of the queue entry whose flink/blink field is NULL
Arg2: fffff800c3284650, The address of the queue being references. Usually this is one
of the ExWorkerQueues.
Arg3: fffff800c3284380, The base address of the ExWorkerQueue array. This will help determine
if the queue in question is an ExWorkerQueue and if so, the offset from
this parameter will isolate the queue.
Arg4: fffff800c2eaad90, If this is an ExWorkerQueue (which it usually is), this is the address
of the worker routine that would have been called if the work item was
valid. This can be used to isolate the driver that is misusing the work
queue.

Debugging Details:
------------------


WORKER_ROUTINE:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

FAULTING_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

WORK_ITEM: ffffb28c63352ce0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x96

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff800c304bdbc to fffff800c2ff83f0

STACK_TEXT:
ffff8b80`621c6ac8 fffff800`c304bdbc : 00000000`00000096 ffffb28c`63352ce0 fffff800`c3284650 fffff800`c3284380 : nt!KeBugCheckEx
ffff8b80`621c6ad0 fffff800`c2eca00e : 00000000`00000000 00000000`00000000 fffff800`c3284650 ffffb28c`6c65e040 : nt!KiAttemptFastRemovePriQueue+0xc929c
ffff8b80`621c6b10 fffff800`c2ec9c50 : 00000000`00000100 ffffb28c`6c65e000 fffff800`c2eaad90 00000000`0000000c : nt!KeRemovePriQueue+0x19e
ffff8b80`621c6b80 fffff800`c2f68a37 : ffffb28c`65772cc0 00000000`00000080 ffffb28c`5ea7d040 ffffb28c`6c65e040 : nt!ExpWorkerThread+0x80
ffff8b80`621c6c10 fffff800`c2ffd876 : ffff8b80`1abde180 ffffb28c`6c65e040 fffff800`c2f689f0 ffff813c`029eaa01 : nt!PspSystemThreadStartup+0x47
ffff8b80`621c6c60 00000000`00000000 : ffff8b80`621c7000 ffff8b80`621c1000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

SYMBOL_NAME: nt!IopProcessWorkItem+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 59327910

IMAGE_VERSION: 10.0.15063.413

BUCKET_ID_FUNC_OFFSET: 0

FAILURE_BUCKET_ID: 0x96_nt!IopProcessWorkItem

BUCKET_ID: 0x96_nt!IopProcessWorkItem

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x96_nt!iopprocessworkitem

FAILURE_ID_HASH: {9b586d9a-c1f6-a6de-4692-9ceab4008b6f}

Followup: MachineOwner
---------

4: kd> !analyze -v
************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************

INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null. This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this. The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: ffffb28c63352ce0, The address of the queue entry whose flink/blink field is NULL
Arg2: fffff800c3284650, The address of the queue being references. Usually this is one
of the ExWorkerQueues.
Arg3: fffff800c3284380, The base address of the ExWorkerQueue array. This will help determine
if the queue in question is an ExWorkerQueue and if so, the offset from
this parameter will isolate the queue.
Arg4: fffff800c2eaad90, If this is an ExWorkerQueue (which it usually is), this is the address
of the worker routine that would have been called if the work item was
valid. This can be used to isolate the driver that is misusing the work
queue.

Debugging Details:
------------------


WORKER_ROUTINE:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

FAULTING_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

WORK_ITEM: ffffb28c63352ce0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x96

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff800c304bdbc to fffff800c2ff83f0

STACK_TEXT:
ffff8b80`621c6ac8 fffff800`c304bdbc : 00000000`00000096 ffffb28c`63352ce0 fffff800`c3284650 fffff800`c3284380 : nt!KeBugCheckEx
ffff8b80`621c6ad0 fffff800`c2eca00e : 00000000`00000000 00000000`00000000 fffff800`c3284650 ffffb28c`6c65e040 : nt!KiAttemptFastRemovePriQueue+0xc929c
ffff8b80`621c6b10 fffff800`c2ec9c50 : 00000000`00000100 ffffb28c`6c65e000 fffff800`c2eaad90 00000000`0000000c : nt!KeRemovePriQueue+0x19e
ffff8b80`621c6b80 fffff800`c2f68a37 : ffffb28c`65772cc0 00000000`00000080 ffffb28c`5ea7d040 ffffb28c`6c65e040 : nt!ExpWorkerThread+0x80
ffff8b80`621c6c10 fffff800`c2ffd876 : ffff8b80`1abde180 ffffb28c`6c65e040 fffff800`c2f689f0 ffff813c`029eaa01 : nt!PspSystemThreadStartup+0x47
ffff8b80`621c6c60 00000000`00000000 : ffff8b80`621c7000 ffff8b80`621c1000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

SYMBOL_NAME: nt!IopProcessWorkItem+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 59327910

IMAGE_VERSION: 10.0.15063.413

BUCKET_ID_FUNC_OFFSET: 0

FAILURE_BUCKET_ID: 0x96_nt!IopProcessWorkItem

BUCKET_ID: 0x96_nt!IopProcessWorkItem

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x96_nt!iopprocessworkitem

FAILURE_ID_HASH: {9b586d9a-c1f6-a6de-4692-9ceab4008b6f}

Followup: MachineOwner
---------

4: kd> !analyze -v
************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************

INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null. This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this. The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: ffffb28c63352ce0, The address of the queue entry whose flink/blink field is NULL
Arg2: fffff800c3284650, The address of the queue being references. Usually this is one
of the ExWorkerQueues.
Arg3: fffff800c3284380, The base address of the ExWorkerQueue array. This will help determine
if the queue in question is an ExWorkerQueue and if so, the offset from
this parameter will isolate the queue.
Arg4: fffff800c2eaad90, If this is an ExWorkerQueue (which it usually is), this is the address
of the worker routine that would have been called if the work item was
valid. This can be used to isolate the driver that is misusing the work
queue.

Debugging Details:
------------------


WORKER_ROUTINE:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

FAULTING_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

WORK_ITEM: ffffb28c63352ce0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x96

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff800c304bdbc to fffff800c2ff83f0

STACK_TEXT:
ffff8b80`621c6ac8 fffff800`c304bdbc : 00000000`00000096 ffffb28c`63352ce0 fffff800`c3284650 fffff800`c3284380 : nt!KeBugCheckEx
ffff8b80`621c6ad0 fffff800`c2eca00e : 00000000`00000000 00000000`00000000 fffff800`c3284650 ffffb28c`6c65e040 : nt!KiAttemptFastRemovePriQueue+0xc929c
ffff8b80`621c6b10 fffff800`c2ec9c50 : 00000000`00000100 ffffb28c`6c65e000 fffff800`c2eaad90 00000000`0000000c : nt!KeRemovePriQueue+0x19e
ffff8b80`621c6b80 fffff800`c2f68a37 : ffffb28c`65772cc0 00000000`00000080 ffffb28c`5ea7d040 ffffb28c`6c65e040 : nt!ExpWorkerThread+0x80
ffff8b80`621c6c10 fffff800`c2ffd876 : ffff8b80`1abde180 ffffb28c`6c65e040 fffff800`c2f689f0 ffff813c`029eaa01 : nt!PspSystemThreadStartup+0x47
ffff8b80`621c6c60 00000000`00000000 : ffff8b80`621c7000 ffff8b80`621c1000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

SYMBOL_NAME: nt!IopProcessWorkItem+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 59327910

IMAGE_VERSION: 10.0.15063.413

BUCKET_ID_FUNC_OFFSET: 0

FAILURE_BUCKET_ID: 0x96_nt!IopProcessWorkItem

BUCKET_ID: 0x96_nt!IopProcessWorkItem

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x96_nt!iopprocessworkitem

FAILURE_ID_HASH: {9b586d9a-c1f6-a6de-4692-9ceab4008b6f}

Followup: MachineOwner
---------

4: kd> !analyze -v
************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************

INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null. This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this. The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: ffffb28c63352ce0, The address of the queue entry whose flink/blink field is NULL
Arg2: fffff800c3284650, The address of the queue being references. Usually this is one
of the ExWorkerQueues.
Arg3: fffff800c3284380, The base address of the ExWorkerQueue array. This will help determine
if the queue in question is an ExWorkerQueue and if so, the offset from
this parameter will isolate the queue.
Arg4: fffff800c2eaad90, If this is an ExWorkerQueue (which it usually is), this is the address
of the worker routine that would have been called if the work item was
valid. This can be used to isolate the driver that is misusing the work
queue.

Debugging Details:
------------------


WORKER_ROUTINE:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

FAULTING_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

WORK_ITEM: ffffb28c63352ce0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x96

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff800c304bdbc to fffff800c2ff83f0

STACK_TEXT:
ffff8b80`621c6ac8 fffff800`c304bdbc : 00000000`00000096 ffffb28c`63352ce0 fffff800`c3284650 fffff800`c3284380 : nt!KeBugCheckEx
ffff8b80`621c6ad0 fffff800`c2eca00e : 00000000`00000000 00000000`00000000 fffff800`c3284650 ffffb28c`6c65e040 : nt!KiAttemptFastRemovePriQueue+0xc929c
ffff8b80`621c6b10 fffff800`c2ec9c50 : 00000000`00000100 ffffb28c`6c65e000 fffff800`c2eaad90 00000000`0000000c : nt!KeRemovePriQueue+0x19e
ffff8b80`621c6b80 fffff800`c2f68a37 : ffffb28c`65772cc0 00000000`00000080 ffffb28c`5ea7d040 ffffb28c`6c65e040 : nt!ExpWorkerThread+0x80
ffff8b80`621c6c10 fffff800`c2ffd876 : ffff8b80`1abde180 ffffb28c`6c65e040 fffff800`c2f689f0 ffff813c`029eaa01 : nt!PspSystemThreadStartup+0x47
ffff8b80`621c6c60 00000000`00000000 : ffff8b80`621c7000 ffff8b80`621c1000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!IopProcessWorkItem+0
fffff800`c2eaad90 48895c2410 mov qword ptr [rsp+10h],rbx

SYMBOL_NAME: nt!IopProcessWorkItem+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 59327910

IMAGE_VERSION: 10.0.15063.413

BUCKET_ID_FUNC_OFFSET: 0

FAILURE_BUCKET_ID: 0x96_nt!IopProcessWorkItem

BUCKET_ID: 0x96_nt!IopProcessWorkItem

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x96_nt!iopprocessworkitem

FAILURE_ID_HASH: {9b586d9a-c1f6-a6de-4692-9ceab4008b6f}

Followup: MachineOwner
---------

4: kd>

Asta e facut cu windbg si ma duce la o cauza cu un driver dar nu e clar

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x96

Pana una alta dau dsi driver updates la tot ce am in pc, poate asa scap de driverul ala generic de windows 8 sau ce rahat o fii.

[agarici cu pedale]

Cred ca l-am gasit pe fraier...

cred ca de la asta era
https://www.pcgarage.ro/adaptoare-bl...us-edr-usb-20/

revin cu update

[reflavius]

99.99 in paranteza )

"fffff802`427e0000 fffff802`427fe000 Microsoft_Bluetooth_Legacy_LEEnumerator T (no symbols)

Unloaded modules:
fffff802`41f90000 fffff802`41fcd000 WUDFRd.sys
fffff802`41f40000 fffff802`41f4b000 cldflt.sys
fffff802`3d9a0000 fffff802`3d9af000 dump_storpor
fffff802`3d9e0000 fffff802`3da07000 dump_storahc
fffff802`3da30000 fffff802`3da4d000 dump_dumpfve
fffff802`3f3b0000 fffff802`3f3d0000 dam.sys
fffff802`3caf0000 fffff802`3caff000 WdBoot.sys
fffff802`3d8a0000 fffff802`3d8af000 hwpolicy.sys
"

[agarici cu pedale]

Yup, de la el era, merci mult.
Ai PM.

Abia ce l-am luat modulul de BT, futu-i si ce ma mai bucuram ca mergea bine.
Oficial cica trebuia sa mearga pe windows 10

[mbc]

Amu daca iei de la producator de speta asta...

Eu am asta: si merge fara probleme: http://www.pcgarage.ro/adaptoare-blu...sus/usb-bt400/

[Snowbawls]

Originally Posted by mbc

Amu daca iei de la producator de speta asta...

Eu am asta: si merge fara probleme: http://www.pcgarage.ro/adaptoare-blu...sus/usb-bt400/

Lasă că nici Asus nu sunt flawless pe partea de driveri sau implementari de accesorii, dar ai și tu dreptate. Producătorii low cost nu prea investesc în QA, ca să nu mai zic de WHQL.

Bine că l-a găsit pe vinovat în final.

Sent from my ONEPLUS A3003 using Tapatalk

[mbc]

Pai nici unul nu e perfect, dar daca ar fi sa risc cu Logilink sau cu Asus, parca as merge cu Asus.

[agarici cu pedale]

Am luat si eu unul ca al tau, vad ca e oke acum. Merci mult all.

[bakhus]

Salut, am primit cadou de la un prieten un upgrade de la 4690k la 4790k.
Totul minunat si frumos, pana am dat primul bench si... m-am ingrozit.
Temperaturi uriase, throttle, horror, sange pe pereti, catelusi si pisoiasi morti, maini taiete, picioare taiete, apa plata, ulei etc.

Pasta e NT-H1, coolerul este Arctic Liquid Freezer 240, MB e AsRock Ex4 z97, memoriile sunt la 1600 deci nu e mare stres pe IMC, IGPU e la 600Mhz.
Au prestat exceptional, tinand 4690k-ul in max 72C la 4,6 cu voltaj destul de mare (1,3), fiind un chip destul de trist...

Ce-am incercat pana acum: pus pompa de 3 ori, redus voltajul core si cache la 1,1V, redus cache-urile la 4Ghz, disabled la force all cores to same speed thingy, nimic, tot zboara in 90+ si throttle.

Singura modalitate sa-l tin sub 85C a fost sa-l tin in 4Ghz/1,040V pe core si cache, ceea ce mi se pare un comprimis trist, avand in vedere ca e totusi pe un cooler care in testele mele a batut NH-D14, nu pe o panarama d-aia mica stock.

Ce-mi scapa? Ce-ar trebui sa-i fac?

[mbc]

Asa-i cu pasta masii de la Intel. Daca ar fi un producator care ar suda toate procesoarele...

[madhorsefuzzy]

Delid.

Sent from my SM-N9005 using Tapatalk

[kretzu77]

Originally Posted by bakhus

Salut, am primit cadou de la un prieten un upgrade de la 4690k la 4790k.
Totul minunat si frumos, pana am dat primul bench si... m-am ingrozit.
Temperaturi uriase, throttle, horror, sange pe pereti, catelusi si pisoiasi morti, maini taiete, picioare taiete, apa plata, ulei etc.

Pasta e NT-H1, coolerul este Arctic Liquid Freezer 240, MB e AsRock Ex4 z97, memoriile sunt la 1600 deci nu e mare stres pe IMC, IGPU e la 600Mhz.
Au prestat exceptional, tinand 4690k-ul in max 72C la 4,6 cu voltaj destul de mare (1,3), fiind un chip destul de trist...

Ce-am incercat pana acum: pus pompa de 3 ori, redus voltajul core si cache la 1,1V, redus cache-urile la 4Ghz, disabled la force all cores to same speed thingy, nimic, tot zboara in 90+ si throttle.

Singura modalitate sa-l tin sub 85C a fost sa-l tin in 4Ghz/1,040V pe core si cache, ceea ce mi se pare un comprimis trist, avand in vedere ca e totusi pe un cooler care in testele mele a batut NH-D14, nu pe o panarama d-aia mica stock.

Ce-mi scapa? Ce-ar trebui sa-i fac?

http://forum.lab501.ro/showthread.php?t=17586

[EXxx]

nu-i doar delid-ul singura solutie, desi de multe ori e foarte buna/eficienta. Mai ales ca un 4790k @ 4.5/4.6 ar trebui sa mai aibe cativa ani in el.
1) ultimul bios. Sunt multe voltaje de tinut sub control, e posibil ca mb sa sara in sus unul dintre ele
2) VCCIN -input voltage- Dai cu 1.7/1.8 fix. Posibil in load sa iti creasca input voltage.

daca vrei viata lunga si usoara cu 4790k delidul e bine de facut.

[bakhus]

Multumesc tuturor pentru ajutor, delid-ul l-as lasa ca ultima solutie.
BIOS-ul e pus ultimul aseara, a fost primul lucru pe care l-am facut.
O sa incerc cu input voltage-ul la 1.7V cand ajung diseara!

[agarici cu pedale]

Daca te referi la tempurile alea in load in prime or some shit bench nu-ti face griji, e normal.

In daily gaming etc va merge mult mai jos.
Ca idee. Al meu pe mach hr 02 cu venturile pe low low facea throtle intr-un minut fiindca imi baga voltaj de 1.25 default (placa mea overvolteaza), in realitate chiar si asa in gaming nu face throtle.

Daca ii dai turbo off si voltaj mic e rece in gaming.

[agarici cu pedale]

Se da o problema - nu am timp sa caut acum exact ca am de alergat , poate stie cineva ceva, dar dintr-un motiv anume (probabil bug pentru ca mai demult nu aveam problema asta pana sa fac clean install de win 10)

facut share - mapat pe android tv - pc-ul nu mai intra in sleep deloc automat dupa 2 ore.
nu stiu daca are legatura directa cu utorrent , inainte aveam qbit dar pis pe el.

nu-mi recomandati sa revin la qbit sub nici o forma fiindca nu poate sa faca upload cum trebuie (si da sunt conectabil si port fw etc, nu vrea, case close)

stie cineva unde-i buba ?

[Bugsy004]

E posibil ca un task de share să îl țină treaz.