[SOLVED] IRQL BSOD Issues

[dasauto3]

I've been suffering from IRQL NOT LESS THAN OR EQUAL TO beginning last Friday.

The BSOD would result in boot loops of BSOD, with a variety of other error messages. I would be unable to boot into safe mode or recovery mode. I was only able to get into BIOS. As a side note, sometimes it would let me boot to windows. It would then promptly crash within a few minutes or, if I was lucky, hours.

I started troubleshooting on my own to figure out the issue. One of the first things I did was run memtest86 on my RAM, I've run my ram indiviudally, as well as dual channel. One thing I noticed was that the error messages were pretty inconsistent. I was only able to run each for 4 passes because of the version of memtest I have, but in some cases I would get no errors, and in others I would get plenty. So, one of the first things I did was replace the RAM. I got brand new ram and memtest picked up errors on the new sticks as well. I also kept getting the same blue screens. Given that I think its highly unlikely to be sent two brand new sticks that are faulty, I moved onto checking other elements.

I then began checking drivers, and uninstalling any new programs. The only updates I recall installing were a windows update. Nevertheless, I reinstalled drivers, flashed bios, and ran driver verifier. I did get a BSOD from driver verifier, but at the time I was unable to boot past windows, so I didn't get a chance to do anything with it.

I also scanned all of my drives using sfc /scannow, as well as dism restore health. Initially, there were errors found using sfc, but aside from the first time, I found no other errors. DISM also didn't report anything was wrong. In addition, I still got blue screens with all of my drives unplugged, and only a windows bootable usb plugged in. Even though I didn't thing my drives were the issue, I reinstalled Windows. This made me believe that it was not a driver error, but a hardware error.

At this point I figured it had to be a hardware issue. Also, at this point, I was three days in and the BSOD errors kept getting worse. The amount of times I could get into windows decreased, from sometimes being able to boot, to not at all. The blue screens themselves sometimes wouldn't even report errors codes, just a frowny face. I went out and bought a new motherboard, new psu, and new cpu. I went through switching out various parts beginning with the psu. New psu didn't change anything. Motherboard didn't change anything either.

However, a new CPU fixed my issue entirely, or so I thought. I had all new hardware in my PC before trying the new CPU. Once installed, it booted immediately. From that point, I worked backward, putting my old hardware back in and booting. Everything went smoothly and now the only new hardware I have in my PC is the CPU. I never saw another BSOD or issue up until now. I was able to boot back up immediately however. I'm just hoping the issues don't continue to get worse like before.

I'm now really unsure what the issue is here. Maybe its a combination of hardware components? Motherboard and CPU? Or maybe hardware and driver issues? I'm going to run Driver Verifier and see if I can get a memory dump from it, since I as unable to boot last time.

It's been a long week and I would appreciate any help.

Below I have my PC specs, as well as the new hardware I purchased. In addition, I have a minidump from the most recent BSOD.

Old Hardware:
CPU: i7-9700k - 3 months old
Motherboard: Asus ROG STRIX Z390-H - 3 months old
GPU: EVGA Geforce GTX 1080 SC Gaming
PSU: Corsair CX600 - ?? years old
RAM: Corsair Vengeance LED DDR4 3000 mHz - CMU16GX4M2C3000C15R - 1.5 years old
Drives: Samsung 850 Evo 250 GB - almost 2 yrs, Samsung 860 Evo 1TB - 3 months old

New Hardware:
CPU: i7-9700k
Motherboard: MSI MPG Z390 Gaming Plus
PSU: Corsair CX650M
RAM: Corsair Vengeance LPX DDR4 3000 mHz - CMK16GX4M2B3000C15

Dump:
I'm not entirely sure how to understand dump files. The IMAGE_NAME towards the bottom of the dmp file says memory corruption. So, does that mean my old memory is corrupted? Also, the process that caused it was chrome.exe?

Path validation summary *
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 18362 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Machine Name:
Kernel base = 0xfffff8013d600000 PsLoadedModuleList = 0xfffff8013da48210
Debug session time: Fri Oct 25 18:31:26.110 2019 (UTC - 4:00)
System Uptime: 1 days 0:41:23.029
Loading Kernel Symbols
...............................................................
................................................................
.............................................................
Loading User Symbols
Loading unloaded module list
.....................................
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff8013d7c1220 48894c2408 mov qword ptr [rsp+8],rcx ss:ffff8685f4f8f340=000000000000000a
3: kd> !analyze -v
***

• *
• Bugcheck Analysis *
• *

***

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: ffffeb47504950d0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8013d679a64, address which referenced memory

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


KEY_VALUES_STRING: 1

Key : Analysis.CPU.Sec
Value: 2

Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on THE_SENATE

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.Sec
Value: 5

Key : Analysis.Memory.CommitPeak.Mb
Value: 70

Key : Analysis.System
Value: CreateObject


DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump

BUGCHECK_CODE: a

BUGCHECK_P1: ffffeb47504950d0

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: fffff8013d679a64

READ_ADDRESS: fffff8013db733b8: Unable to get MiVisibleState
Unable to get NonPagedPoolStart
Unable to get NonPagedPoolEnd
Unable to get PagedPoolStart
Unable to get PagedPoolEnd
fffff8013da2a3c8: Unable to get Flags value from nt!KdVersionBlock
fffff8013da2a3c8: Unable to get Flags value from nt!KdVersionBlock
unable to get nt!MmSpecialPagesInUse
ffffeb47504950d0

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: chrome.exe

TRAP_FRAME: ffff8685f4f8f480 -- (.trap 0xffff8685f4f8f480)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffeb0000000000 rbx=0000000000000000 rcx=ffff8685f4f8f780
rdx=ffff8685f4f8fa00 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8013d679a64 rsp=ffff8685f4f8f610 rbp=ffff8685f4f8f810
r8=ffff8ea092a1ae20 r9=0000007ffffffff8 r10=ffffeb0000000000
r11=ffff8685f4f8fa00 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!MiResolveProtoPteFault+0xc4:
fffff8013d679a64 4c8b0b mov r9,qword ptr [rbx] ds:0000000000000000=????????????????
Resetting default scope

STACK_TEXT:
ffff8685f4f8f338 fffff8013d7d30e9 : 000000000000000a ffffeb47504950d0 0000000000000002 0000000000000000 : nt!KeBugCheckEx
ffff8685f4f8f340 fffff8013d7cf42b : 0000000000000000 0000000000000000 0000000000000001 0a00000308ea4025 : nt!KiBugCheckDispatch+0x69
ffff8685f4f8f480 fffff8013d679a64 : ffff8685f4f8f780 0a00000308ea4121 0000000000000000 000078f600000000 : nt!KiPageFault+0x46b
ffff8685f4f8f610 fffff8013d674bbc : ffff8685f4f8f780 0000000000000000 ffff8685f4f8f758 fffff8013d673cb4 : nt!MiResolveProtoPteFault+0xc4
ffff8685f4f8f710 fffff8013d672cf9 : 0000000000000110 0000000000000100 00000000c0000016 000078f613cb4000 : nt!MiDispatchFault+0x80c
ffff8685f4f8f860 fffff8013d7cf320 : 0000000000000000 ffff8685f4f8fa80 0000000000000018 fffffffffff0e4d0 : nt!MmAccessFault+0x169
ffff8685f4f8fa00 00007ff9887041e0 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiPageFault+0x360
000000f7475fa5f8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007ff9`887041e0


SYMBOL_NAME: nt!MiResolveProtoPteFault+c4

MODULE_NAME: nt

IMAGE_VERSION: 10.0.18362.418

STACK_COMMAND: .thread ; .cxr ; kb

IMAGE_NAME: memory_corruption

BUCKET_ID_FUNC_OFFSET: c4

FAILURE_BUCKET_ID: AV_nt!MiResolveProtoPteFault

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {2f2238e9-4751-e3c3-543c-b0cdf930b219}

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

Also, if I break any rules, I'm sorry. I looked over them and don't think I am, but this is my first time posting on any sort of forum like this.

 

[dasauto3]

So, I managed to run driver verifier. Got a DRIVER VERIFIER IOMANAGER VIOLATION (wdf01000.sys). Rebooted and opened the dump files.

Found a similar issue: View: https://www.reddit.com/r/Windows10/comments/4oleji/driver_verifier_iomanager_violation_wdf01000sys/
.

Apparently the issue was related to a driver (vmulti) from a drawing tablet that I had however many months or years ago. I just decided to uninstall it since I don't use it anymore.

If the issue is fixed, I'm wondering if this was the issue all along. To me, it seems very unlikely that a driver like the one I uninstalled would call for me to replace my CPU. Maybe it was just a combination of a variety of different issues?

I'll keep this post updated if I suffer from any more issues.

 

[Colif]

a driver for a tablet is unlikely to be the cause of boot loops, and BSOD in safe mode, so it is possible replacing CPU was also needed. CPU is where memory controller is, so have you tried testing the 1st ram sticks again on PC as if the errors were random, it may be the CPU was the cause.

Did you run Intel Processor Diagnostic Tool at any stage? Prime95?

Did you upload minidump showing the driver verifer BSOD?

 

[dasauto3]

I wasn't able to run any sort of CPU diagnostic tool previously because of the constant blue screening. I'm going to test the ram again overnight and then test the CPU. Is Prime95 preferred? Or should I run both?

Here is the dump from the driver verifier BSOD.

Path validation summary *
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 18362 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Machine Name:
Kernel base = 0xfffff8066c2a4000 PsLoadedModuleList = 0xfffff8066c6ec210
Debug session time: Fri Oct 25 19:39:34.126 2019 (UTC - 4:00)
System Uptime: 0 days 0:00:05.870
Loading Kernel Symbols
...............................................................
................................................................
...
Loading User Symbols
Loading unloaded module list
...
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff8066c465220 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:ffffd70bd33b6cd0=00000000000000c9
0: kd> !analyze -v
***

• *
• Bugcheck Analysis *
• *

***

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 000000000000022e, The caller has completed a successful IRP_MJ_PNP instead of passing it down.
Arg2: fffff8066d5daac0, The address in the driver's code where the error was detected.
Arg3: ffff840c7d6a0d80, IRP address.
Arg4: 0000000000000000

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


KEY_VALUES_STRING: 1

Key : Analysis.CPU.Sec
Value: 1

Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on THE_SENATE

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.Sec
Value: 33

Key : Analysis.Memory.CommitPeak.Mb
Value: 75

Key : Analysis.System
Value: CreateObject


DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump

BUGCHECK_CODE: c9

BUGCHECK_P1: 22e

BUGCHECK_P2: fffff8066d5daac0

BUGCHECK_P3: ffff840c7d6a0d80

BUGCHECK_P4: 0

DRIVER_VERIFIER_IO_VIOLATION_TYPE: 22e

IRP_ADDRESS: ffff840c7d6a0d80

DEVICE_OBJECT: ffff840c79478060

BLACKBOXNTFS: 1 (!blackboxntfs)


CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

STACK_TEXT:
ffffd70bd33b6cc8 fffff8066cc136e3 : 00000000000000c9 000000000000022e fffff8066d5daac0 ffff840c7d6a0d80 : nt!KeBugCheckEx
ffffd70bd33b6cd0 fffff8066cc1a947 : 0000000000000000 0000000000000000 000000000000022e fffff8066cc658c0 : nt!VerifierBugCheckIfAppropriate+0xdf
ffffd70bd33b6d10 fffff8066c5cd7af : 000000000000022e ffff840c7d6a0d80 ffff840c7d6a0d80 0000000000000000 : nt!ViErrorFinishReport+0x117
ffffd70bd33b6d70 fffff8066cc1a5ed : 0000000000000001 0000000000000000 ffffd70b00000000 0000000000000000 : nt!ViErrorReport1+0x63
ffffd70bd33b6e10 fffff8066cc251a8 : 0000000000000000 0000000400000002 0000000000000000 00007fff00000001 : nt!VfErrorReport1+0x9
ffffd70bd33b6e40 fffff8066cc1a41c : ffff840c794791c8 0000000000000001 0000000000000000 0000000000001000 : nt!VfPnpVerifyIrpStackUpward+0x158
ffffd70bd33b6ea0 fffff8066cc12f83 : ffff840c7d6a0d80 0000000000000000 0000000000000001 ffff840c7cdfae30 : nt!VfMajorVerifyIrpStackUpward+0x74
ffffd70bd33b6ef0 fffff8066cc088f6 : ffff840c7d6a0d80 fffff8066c30f52d ffffffff00000000 0000000000001000 : nt!IovpCompleteRequest2+0xe3
ffffd70bd33b6f60 fffff8066c2eb799 : ffff840c7d6a0d80 0000000000000004 ffffc0058ee4e806 ffffd70bd33b7069 : nt!IovpLocalCompletionRoutine+0x96
ffffd70bd33b6fc0 fffff8066cc08315 : ffff840c7d6a0d80 ffffd70bd33b7100 0000000000000024 ffff840c79479150 : nt!IopfCompleteRequest+0x119
ffffd70bd33b70d0 fffff8066c49f211 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!IovCompleteRequest+0x1e1
ffffd70bd33b71c0 fffff8066d540190 : 0000000000000013 ffff840c7bc1aff0 fffff80650124000 00007bf3842d52f8 : nt!IofCompleteRequest+0x1b3bc1
ffffd70bd33b71f0 fffff8066cc0c480 : 0000000000000000 000000000000001b ffff840c7a3e2fd0 ffff840c7d6a0d80 : VerifierExt!IofCompleteRequest_wrapper+0x140
ffffd70bd33b7240 fffff806500e12e8 : ffff840c7d6a0ee0 0000000000000288 ffff840c7d6a0ee0 fffff806500f61d2 : nt!VerifierIofCompleteRequest+0x10
ffffd70bd33b7270 ffff840c7d6a0ee0 : 0000000000000288 ffff840c7d6a0ee0 fffff806500f61d2 ffff840c7bd2ad00 : vmulti+0x12e8
ffffd70bd33b7278 0000000000000288 : ffff840c7d6a0ee0 fffff806500f61d2 ffff840c7bd2ad00 fffff8066d5dacae : 0xffff840c7d6a0ee0 ffffd70bd33b7280 ffff840c7d6a0ee0 : fffff806500f61d2 ffff840c7bd2ad00 fffff8066d5dacae ffff840c7d6a0d80 : 0x288 ffffd70bd33b7288 fffff806500f61d2 : ffff840c7bd2ad00 fffff8066d5dacae ffff840c7d6a0d80 0000000000000288 : 0xffff840c7d6a0ee0
ffffd70bd33b7290 ffff840c77e2ade0 : 0000000000000020 0000000000400000 0000000000000000 fffff80650124000 : mshidkmdf!HidKmdfPnp+0x92
ffffd70bd33b72c0 0000000000000020 : 0000000000400000 0000000000000000 fffff80650124000 0000000000400000 : 0xffff840c77e2ade0 ffffd70bd33b72c8 0000000000400000 : 0000000000000000 fffff80650124000 0000000000400000 ffff840c73c76cd0 : 0x20 ffffd70bd33b72d0 0000000000000000 : fffff80650124000 0000000000400000 ffff840c73c76cd0 ffff840c`7d6a0d80 : 0x400000


FAULTING_SOURCE_LINE: minkernel\wdf\framework\shared\core\fxdevice.cpp

FAULTING_SOURCE_FILE: minkernel\wdf\framework\shared\core\fxdevice.cpp

FAULTING_SOURCE_LINE_NUMBER: 1368

FAULTING_SOURCE_CODE:
No source found for 'minkernel\wdf\framework\shared\core\fxdevice.cpp'


SYMBOL_NAME: Wdf01000!FxDevice:: DispatchWithLock+0

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

IMAGE_VERSION: 1.29.18362.10013

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: 0

FAILURE_BUCKET_ID: 0xc9_22e_Wdf01000!FxDevice:: DispatchWithLock

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {50fd45a7-f6f7-7399-9293-72e29e084de4}

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

 

[Colif]

Yeah, I see Vmulti there. That wasn't exactly what I meant, it is my fault though

Can you follow steps in 1st post here - https://forums.tomshardware.com/thr...nclude-in-blue-screen-of-death-posts.3468965/

Prime95: I was asking more of a historical thing, as if you have replaced CPU now, the new one shouldn't need to have those tests run on it. When testing CPU I would have run both, as IPDT has been known to miss problems before.

 

[dasauto3]

I was unable to test the first CPU with Prime95 or IPDT, because by the time I even considered running any CPU diagnostic tool, I was already unable to boot whatsoever.

I did go ahead and run both on the current CPU because I figured why not. IPDT passed. I ran the Prime95 torture test, and worker #4 has failed 14 min in. I read around a bit, and it could possibly be bad/mixed ram? I have both sets of sticks in right now, which I'm assuming might be the problem. I only put them both in because they run at the same voltage and timings. Should I run Prime95 again which only one set in at a time before moving to memtest?

Prime95 Log:

[Oct 25 21:37] Worker starting
[Oct 25 21:37] Beginning a continuous self-test on your computer.
[Oct 25 21:37] Please read stress.txt. Choose Test/Stop to end this test.
[Oct 25 21:37] Test 1, 52000 Lucas-Lehmer iterations of M5705025 using FMA3 FFT length 288K, Pass1=384, Pass2=768, clm=4.
[Oct 25 21:40] Self-test 288K passed!
[Oct 25 21:40] Test 1, 7000000 Lucas-Lehmer in-place iterations of M83839 using FMA3 FFT length 4K.
[Oct 25 21:42] Test 2, 7000000 Lucas-Lehmer in-place iterations of M82031 using FMA3 FFT length 4K.
[Oct 25 21:43] Test 3, 7000000 Lucas-Lehmer in-place iterations of M79745 using FMA3 FFT length 4K.
[Oct 25 21:44] Self-test 4K passed!
[Oct 25 21:44] Test 1, 52000 Lucas-Lehmer iterations of M6225921 using FMA3 FFT length 320K, Pass1=320, Pass2=1K, clm=4.
[Oct 25 21:47] Self-test 320K passed!
[Oct 25 21:47] Test 1, 6000000 Lucas-Lehmer in-place iterations of M104799 using FMA3 FFT length 5K.
[Oct 25 21:49] Test 2, 6000000 Lucas-Lehmer in-place iterations of M102991 using FMA3 FFT length 5K.
[Oct 25 21:50] Self-test 5K passed!
[Oct 25 21:50] Test 1, 44000 Lucas-Lehmer iterations of M6684673 using FMA3 FFT length 336K, Pass1=448, Pass2=768, clm=4.
[Oct 25 21:52] FATAL ERROR: Rounding was 0.5, expected less than 0.4
[Oct 25 21:52] Hardware failure detected, consult stress.txt file.
[Oct 25 21:52] Torture Test completed 7 tests in 14 minutes - 1 errors, 0 warnings.
[Oct 25 21:52] Worker stopped.

Here are both dump files.
IRQL BSOD:
https://drive.google.com/open?id=1TJ3lf9e9aIcChHL4cb1iGY1iRTdYgX18
Driver Verifier BSOD:
https://drive.google.com/open?id=1LGEIT0IAZ4R8iJgliukNb9sV3S_d05tO

 

[Colif]

Yes, only have 1 set of sticks in

I have sent dumps to a friend

If you keep getting the rounding error, it can be voltages on CPU.

 

[gardenman]

Hi, I ran the dump files through the debugger and got the following information: https://pste.eu/p/2tkC.html

File information:	102519-9187-01.dmp (Oct 25 2019 - 18:31:26)
Bugcheck:	IRQL_NOT_LESS_OR_EQUAL (A)
Probably caused by:	memory_corruption (Process: chrome.exe)
Uptime:	1 Day(s), 0 Hour(s), 41 Min(s), and 23 Sec(s)

File information:	102519-7437-01.dmp (Oct 25 2019 - 19:39:34)
Bugcheck:	DRIVER_VERIFIER_IOMANAGER_VIOLATION (C9)
Driver warnings:	*** WARNING: Unable to verify timestamp for vmulti.sys
Probably caused by:	Wdf01000.sys (Process: System)
Uptime:	0 Day(s), 0 Hour(s), 00 Min(s), and 05 Sec(s)

Possible Motherboard page: https://www.asus.com/Motherboards/ROG-STRIX-Z390-H-GAMING/HelpDesk/
You have the latest BIOS already installed.

On the 2nd dump, it appears as if vmulti.sys crashed. I've seen 2 descriptions for this file. One place says it's a Mirosoft HID driver (mouse driver), another says it's a driver from Shenzhen Huion Animation Technology Co.,TLD. https://www.freefixer.com/library/file/vmulti.sys-154551/ I don't know which one is correct.

This information can be used by others to help you. I can't help you with this. Someone else will post with more information. Please wait for additional answers. Good luck.

 

[dasauto3]

The vmulti.sys driver is from Shenzhen Huion Animation Technology Co.,TLD . It was the driver for a small drawing tablet I had. I've since uninstalled it and haven't had any blue screens.

I've gone ahead and run memtest86 on all the RAM sticks and none of the have shown errors. I ran the old ram by itself, as well as the new ram. I only tested dual channel however.

I also continued running Prime95. The first time I ran it, I got an error within 15 minutes. The next time I ran it, my computer abruptly shut down about an hour in, but did not blue screen. I was doing other stuff in the background at the time, so I'm not sure if it was related to Prime95, but I assume it was. The next time I ran it, I went for 8hrs without an error. I'm going to sleep now, but Prime95 has been running for around 7hrs with no error.

I haven't had any more blue screens, so I believe my issues might be solved. But I also haven't gotten a chance to use my computer like I normally do, so I guess we will see.

 

[Colif]

i think you will find a file in the Prime95 install folder called stress.txt which should have results of the tests in there.

 

[dasauto3]

The stress.txt folder only gives general background info and faq about stress testing. I went ahead and read it. There is a results.txt, but it just shows the logs of each worker.

Going on 15 hours and it still hasn't gotten an error.