Windows 7: Clock Watchdog Timeout BSOD's During Gaming, Log Zip provided

**axe0** · 15 Aug 2018

How's it going with the scans?

MadVladtheRadDa · 16 Aug 2018

Pardon the delay, rough couple of days. Here they are, I had run SuperAntiSpyware a few days before posting here, so the log ended up being rather short. I dont have the old one, but I recall it being quite extensive, consisting entirely of a huge list of tracking cookies.

**axe0** · 16 Aug 2018

Please don't forget Malwarebytes.

Looks like my suspicion was right, there are/were more files present related to piracy. Please ensure that everything found is removed.

MadVladtheRadDa · 16 Aug 2018

Oops! I'll just post it right here, its in swedish but you should probably get the gist of it.

Malwarebytes
Free Antivirus Replacement & Anti-Malware Tool | Malwarebytes

-Logginformation-
Datum för genomsökningen: 2018-08-14
Tid för genomsökningen: 07:08
Loggfil: 164374f1-9f80-11e8-bfbb-408d5c5c1711.json
Administratör: Ja

-Programvaruinformation-
Version: 3.5.1.2522
Komponentversion: 1.0.391
Uppdatera paketversionen: 1.0.6331
Licens: Testversion

-Systeminformation-
OS: Windows 7 Service Pack 1
CPU: x64
Filsystem: NTFS
Användare: System

-Sammanfattning av genomsökning-
Typ av genomsökning: Genomsökning efter hot
Genomsökning startades av: Schemaläggare
Resultat: Slutförd
Genomsökta objekt: 266902
Upptäckta hot: 0
(Inga skadliga objekts har upptäckts)
Objekt satta i karantän: 0
(Inga skadliga objekts har upptäckts)
Tid som gått: 9 min, 49 sek

-Alternativ för genomsökning-
Minne: Aktiverat
Start: Aktiverat
Filsystem: Aktiverat
Arkiv: Aktiverat
Spökprogram: Avaktiverat
Heuristik: Aktiverat
Potentiellt oönskat program: Hitta
Potentiellt oönskad ändring: Hitta

-Information om genomsökning-
Process: 0
(Inga skadliga objekts har upptäckts)

Modul: 0
(Inga skadliga objekts har upptäckts)

Registernyckel: 0
(Inga skadliga objekts har upptäckts)

Registervärde: 0
(Inga skadliga objekts har upptäckts)

Registerdata: 0
(Inga skadliga objekts har upptäckts)

Dataflöde: 0
(Inga skadliga objekts har upptäckts)

Mapp: 0
(Inga skadliga objekts har upptäckts)

Fil: 0
(Inga skadliga objekts har upptäckts)

Fysisk sektor: 0
(Inga skadliga objekts har upptäckts)

WMI: 0
(Inga skadliga objekts har upptäckts)

(end)

And yes, everything that the scans found has been removed already.

**axe0** · 16 Aug 2018

Excellent, please follow post 2 again

Clock Watchdog Timeout BSOD's During Gaming, Log Zip provided

MadVladtheRadDa · 16 Aug 2018

There you go. Ran into an error when running the command towards the end about a missing file, but it still completed.

**axe0** · 17 Aug 2018

Thank you for providing a kernel dump, exactly what was needed

Please update the Intel Ethernet network driver from Gigabyte, after 1.5 years there is an update available.

On to the analysis itself, the first thing I believe many do is to check the state of all processors, given that we're dealing with a crash where 1 processor has hung.
In order to do this properly I first needed to switch to the processor that hung. To those that don't know why/how, in basic terms this crash occurs because a processor is not responding to requests in an orderly fashion, as this can cause severe problems another processor needs to take action and crashes the system.

Code:

Bugcheck code 00000101
Arguments 00000000`00000031 00000000`00000000 fffff880`035bb180 00000000`00000003
0: kd> ~3

3: kd> !ipi
IPI State for Processor 0

    As a sender, awaiting IPI completion from processor(s) 3.

    TargetCount          1  PacketBarrier        1  IpiFrozen     0 [Running]


IPI State for Processor 1

    As a sender, awaiting IPI completion from processor(s) 3.

    TargetCount          1  PacketBarrier        1  IpiFrozen     2 [Frozen]


IPI State for Processor 2

    As a sender, awaiting IPI completion from processor(s) 3.

    TargetCount          1  PacketBarrier        1  IpiFrozen     2 [Frozen]


IPI State for Processor 3

    As a receiver, unhandled requests are pending from processor(s) 0, 1, 2.

    TargetCount          0  PacketBarrier        0  IpiFrozen     5 [Target Freeze]

    From processor 0, active request of type: flush all
    From processor 1, active request of type: flush multiple
        Flush Count 0  Flush List fffff88008e966a0  (dp fffff88008e966a0 l0)
    From processor 2, active request of type: flush multiple
        Flush Count 0  Flush List fffff880041362f0  (dp fffff880041362f0 l0)

Processors 0, 1 and 2 are waiting for processor 3 to handle requests, but for some reason processor 3 freezes. Now, let's see what the processor was doing.

For some understanding, when you look at task manager you see a lot of processes running in the background. A process is merely a container for something that does the actual work which is called a thread. A process can have hundreds of threads each doing their own thing, all these threads perform tasks simultaneously so the user doesn't have to wait. So a process making calculations like 1+2, 3*15, etc. is quickly done with 1 thread. However, when there are thousands or even billions of calculations to be done, 1 thread will need a second to perform them all (1 calculation = 1 hertz, 1.000.000.000 calculations = 1.0 Ghz per second), when there are 2 threads it will only take half a second, 10 threads and you will nearly instantly see the resuls.

Code:

3: kd> !thread
THREAD fffff880035ca140  Cid 0000.0000  Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 3
Not impersonating
DeviceMap                 fffff8a000006100
Owning Process            fffff80003c07680       Image:         Idle
Attached Process          fffffa800cd70040       Image:         System
Wait Start TickCount      0              Ticks: 497891 (0:02:09:27.149)
Context Switch Count      10337277       IdealProcessor: 0             
UserTime                  00:00:00.000
KernelTime                01:10:07.643
Win32 Start Address nt!KiIdleLoop (0xfffff80003ab4de0)
Stack Init fffff880035eac70 Current fffff880035eac00
Base fffff880035eb000 Limit fffff880035e5000 Call 0000000000000000
Priority 16 BasePriority 0 PriorityDecrement 0 IoPriority 0 PagePriority 0
Child-SP          RetAddr           : Args to Child                                                           : Call Site
00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0

This is the strange part, a thread with nothing going on. This made me very curious. I can't explain why this happened, but upon further investigation I noticed that this thread does make a lot of network related calls. The Intel ethernet driver strangely made many calls using 1 function, DriverEntry, this function initializes a driver after it's been loaded. As this function is repeatedly being called I believe the driver had issues initializing. Unfortunately I have been unable to get the return value of this function to confirm that it fails or not, and if so why.

MadVladtheRadDa · 17 Aug 2018

Very interesting. I will update said driver as soon as I get home from work, then Ill try to get it to crash again.Unfortunately this could either happen really quick, or it might take several days to get a proper dump, as sometimes no BSOD happens when a crash occurs.

MadVladtheRadDa · 05 Sep 2018

Just as I was about to write this one off as solved, a hard freeze occurs. Unfortunately no BSOD occured, so I don't have a log to offer as of yet.

Edit: probably false alarm, turns out some of the power settings reset, most notably the hard drive shutdown feature. That one was probably the culprit, but I'll give it another couple of days.

Second Edit: happened again, so the problem is still persisting. I've yet to acquire any BSOD logs however.

MadVladtheRadDa · 10 Sep 2018

Finally managed to produce another BSOD, latest dump and MEMORY file included in the link. Interesting thing to note however, in my Windows folder there is a LiveKernelReports folder. I was unaware of such a thing even existing and inside I found several .dmp files. A lot of their creation dates coincided with hard freezes without BSOD's I've been having and when viewed in WinDbg every single one I looked at had the GRAPHICS_DRIVER_TDR_TIMEOUT bucket ID and pointed towards nvlddmkm being the culprit. Could this be related, or am I barking up the wrong tree? Should I packet up the KernelReports and post them here?

Dropbox - MEMORY.zip