BSOD minidump analysis

I3LiNdSp0t · Mar 1, 2014

Hello aLL...

I build a new Pc [hoover mouse on avatar to see specs] 3 weeks ago and after the 1st 2 weeks of crashes, I figured out the RAM was corrupted.
The RAM has been replaced, I reInstalled w7 Ultimate x64 [Legit Copy] yesterday and got a few BSOD again =(

So, now it is time to ask a Expert to prettyplease take a look at my MiniDump Files and possibly explain whats going on and help a brother out =D

Besides replacing the RAM and reInstalling the OS, I haven't done anything else sofar but installing some software needed like CCleaner and Flashplayer type of things, the basics.

The OS and programs are on the SSD and the rest like Games and other storage is on the HDD.
They occure random, running different programs, playing a game and even on Idle. The errors are somewhat the same, but the source is different each time.
SFC scan done, nothing out of order.
I reseated GPU and CPU too before I did a fresh install.

Windows is up to date
Drivers are up to date [DriverBooster], but this is my 1st new fresh build and drivers are just wierd.
Temps are all good.

This is where I don't know what to do next, before doing anything stupid or unreversable ofcourse.
I am currently running in Safe Mode and sofar so good.

My latest dump files: http://www.megafileupload.com/en/file/503677/Minidump-rar.html

I hope someone can have a look at it and point me in the right direction. If I have forgotten anything, please ask.

TyVm for reading!

PeaCe

neieus · Mar 1, 2014

I would be willing to look at the dump files but I'm hesitant to download anything. (No offense) How many dumps do you have? Have you tried using whocrashed or Windows Debugger to view the dumps? If so you could post the information provided for all to see. The important thing about reviewing is the more dumps you have the better because it helps us find a common pattern.

I3LiNdSp0t · Mar 1, 2014

I rarred 4 minidumpfiles. I have used WinDbg x64, I can read, but have no clue what I am looking at. Theres alot of info and thought uploading the files was easier.

How do I copy the WinDbg info? Here is a screenshot from 1: http://i1247.photobucket.com/albums/gg627/DeJoHnNiE/WinDbgInfo_zps8396d1ed.png

neieus · Mar 1, 2014

Just highlight the text you want to copy like anything else and use copy/paste.

The information provided in that screen shot is exactly what we need to see.

I3LiNdSp0t · Mar 1, 2014

neieus :

Alright, will do... Apparently it didn't update properly yet, the pc is installing 151 Windows updates atm and I have to run out for a bit.

When I get back, I wll Edit this post and provide the info from the 4 MiniDump Files I uploaded.

Thanks for looking into it...

PeaCe

neieus · Mar 1, 2014

I3LiNdSp0t :

Ok here's the thing... since you're PC wasn't fully updated reading the current batch of crash dumps are pointless. Before troubleshooting anything especially crash dumps you need to make sure all of your windows files and drivers are up to date first! So what I'm trying to say is you can't trust any of the dumps you had before updating and trying to figure out the problem based on those would have been pointless. So make sure all updates have been applied to your windows and make sure you have all the latest drivers to any other device you have from mother board drives to video card or anything else you have connected. Then if your computer starts to crash again THEN post your information.

I3LiNdSp0t · Mar 1, 2014

Fair enough... I did have atleast 2 BSOD's a day before I replaced the faulty RAM and because I got them again after the fresh install, I came here to have it analyzed to see what else might be the problem.

It took 3x to have Windows take the Updates and now only 6 have failed of the 151 updates.

I will leave it running now and see how it goes and if any previous issues occure again, I will get back here with the MiniDump file but I hope not ofcourse.

Thanks for the replies.

PeaCe

I3LiNdSp0t · Mar 1, 2014

And here we go... @18.07 [GMT+1]

*******************************************************************************
* *
* 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: fffff80000bb2f00, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff80002ec94a1, address which referenced memory

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

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800030f6100
GetUlongFromAddress: unable to read from fffff800030f61c0
fffff80000bb2f00 Nonpaged pool

CURRENT_IRQL: 2

FAULTING_IP:
nt!KiTimerExpiration+81
fffff800`02ec94a1 44888c24a0000100 mov byte ptr [rsp+100A0h],r9b

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xA

PROCESS_NAME: mscorsvw.exe

TAG_NOT_DEFINED_c000000f: FFFFF80000BA2FB0

TRAP_FRAME: fffff6fc40005f70 -- (.trap 0xfffff6fc40005f70)
Unable to read trap frame at fffff6fc`40005f70

EXCEPTION_RECORD: fffff6fc4002a368 -- (.exr 0xfffff6fc4002a368)
Cannot read Exception record @ fffff6fc4002a368

LAST_CONTROL_TRANSFER: from fffff80002ebe169 to fffff80002ebebc0

STACK_TEXT:
fffff800`00ba2b88 fffff800`02ebe169 : 00000000`0000000a fffff800`00bb2f00 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff800`00ba2b90 fffff800`02ebcde0 : 00000000`00000000 00000000`00000000 fffffa80`3e3af060 00000001`8a16e2b0 : nt!KiBugCheckDispatch+0x69
fffff800`00ba2cd0 fffff800`02ec94a1 : 00000001`8a155c10 fffff800`00ba2e88 00000000`0000a58d fffff800`0303d428 : nt!KiPageFault+0x260
fffff800`00ba2e60 fffff800`02ec93c7 : fffff800`03039ec3 fffffa80`0000a58e fffffa80`09d10d40 00000000`0000008d : nt!KiTimerExpiration+0x81
fffff800`00ba2f00 fffff800`02ec1d15 : 00000000`00000000 fffffa80`3e3af060 00000000`00000000 fffff880`03c52588 : nt!KiRetireDpcList+0x277
fffff800`00ba2fb0 fffff800`02ec1b2c : 00000000`00000003 fffff800`02e0a895 fffff800`02e30460 fffff880`08e844f0 : nt!KxRetireDpcList+0x5
fffff880`08e84430 fffff800`02f09b53 : fffff800`02ebb140 fffff800`02ebb1ac 00000000`00000001 fffff880`00bef003 : nt!KiDispatchInterruptContinue
fffff880`08e84460 fffff800`02ebb1ac : 00000000`00000001 fffff880`00bef003 00000000`00000000 fffff880`00bef000 : nt!KiDpcInterruptBypass+0x13
fffff880`08e84470 fffff800`03199186 : fffff6fc`4002a368 fffffa80`0bc4c360 fffff6fc`40005f70 fffffa80`0125c640 : nt!KiInterruptDispatchNoLock+0x1fc
fffff880`08e84600 fffff800`03195287 : fffff800`00000000 00000000`00000000 00000000`000008ac fffff8a0`09e3b000 : nt!MiPerformFixups+0xb6
fffff880`08e84660 fffff800`02e9fa92 : fffffa80`012489c0 00000000`008ab000 fffffa80`0125c640 fffff8a0`09c745a8 : nt!MiRelocateImagePfn+0xf7
fffff880`08e846c0 fffff800`031993b1 : fffffa80`3dfd1860 fffff6fc`4002a368 fffff8a0`00000002 00000000`00000000 : nt!MiValidateImagePages+0x362
fffff880`08e84770 fffff800`031994f0 : ffffffff`ffffffff 00000000`00000001 fffff8a0`09e3b000 00000000`000000be : nt!MiSwitchBaseAddress+0x61
fffff880`08e847a0 fffff800`031bbf7f : 00000000`00000004 00000000`00000080 00000000`01000000 00000000`01000000 : nt!MiRelocateImageAgain+0x100
fffff880`08e847f0 fffff800`03198c2e : fffff880`08e84a40 fffff880`08e84b60 00000000`00000000 fffff880`08e84a38 : nt!MmCreateSection+0x2df
fffff880`08e849f0 fffff800`02ebde53 : fffffa80`3e3af060 00000000`000bdc58 fffff880`08e84a88 00000000`00000000 : nt!NtCreateSection+0x171
fffff880`08e84a70 00000000`770b175a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`000bdc38 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x770b175a

STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -db !nt
2 errors : !nt (fffff80002ec94a7-fffff80002ec9527)
fffff80002ec94a0 00 44 88 8c 24 a0 00 *01 00 ff c5 40 0f b6 c5 4c .D..$......@...L
...
fffff80002ec9520 e0 05 42 c7 84 28 1c *03 00 00 ff ff ff ff 41 83 ..B..(........A.

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: STRIDE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_STRIDE

BUCKET_ID: X64_MEMORY_CORRUPTION_STRIDE

Followup: memory_corruption
---------

I3LiNdSp0t · Mar 1, 2014

Now I was playing a game, crashed @19.14

*******************************************************************************
* *
* 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: 0000000000000011, memory referenced
Arg2: 000000000000000d, 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: fffff80002e83f4a, address which referenced memory

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

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800030b0100
GetUlongFromAddress: unable to read from fffff800030b01c0
0000000000000011 Nonpaged pool

CURRENT_IRQL: d

FAULTING_IP:
nt!KiSecondaryClockInterrupt+13a
fffff800`02e83f4a ff11 call qword ptr [rcx]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffff880009ff820 -- (.trap 0xfffff880009ff820)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000f3f6b5c6 rbx=0000000000000000 rcx=0000000000000011
rdx=000000000000ca58 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002e83f4a rsp=fffff880009ff9b8 rbp=fffff880009ffa40
r8=000000000000f0d5 r9=0000000000000000 r10=000000000002cf9f
r11=fffffa8014e84c58 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di ng nz na po nc
nt!KiSecondaryClockInterrupt+0x13a:
fffff800`02e83f4a ff11 call qword ptr [rcx] ds:00000000`00000011=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002e78169 to fffff80002e78bc0

STACK_TEXT:
fffff880`009ff6d8 fffff800`02e78169 : 00000000`0000000a 00000000`00000011 00000000`0000000d 00000000`00000000 : nt!KeBugCheckEx
fffff880`009ff6e0 fffff800`02e76de0 : fffffa80`09bd9000 fffffa80`09bd9000 fffffa80`0af0e000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009ff820 fffff800`02e83f4a : 00000000`00000011 00000000`00000000 fffff880`009ffa40 fffff880`009b3180 : nt!KiPageFault+0x260
fffff880`009ff9b8 fffff880`11dd97f2 : fffff800`02e81709 00000000`003e7a12 fffffa80`0a782868 fffff880`009be040 : nt!KiSecondaryClockInterrupt+0x13a
fffff880`009ffb58 fffff800`02e81709 : 00000000`003e7a12 fffffa80`0a782868 fffff880`009be040 00000000`00000001 : amdppm+0x37f2
fffff880`009ffb60 fffff800`02e7089c : fffff880`009b3180 fffff880`00000000 00000000`00000000 fffff880`02c044d0 : nt!PoIdle+0x52a
fffff880`009ffc40 00000000`00000000 : fffff880`00a00000 fffff880`009fa000 fffff880`009ffc00 00000000`00000000 : nt!KiIdleLoop+0x2c

STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff80002e83f44 - nt!KiSecondaryClockInterrupt+134
[ 8b:9b ]
1 error : !nt (fffff80002e83f44)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: ONE_BIT

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT

BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT

Followup: memory_corruption
---------

And another @20.12

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

ATTEMPTED_SWITCH_FROM_DPC (b8)
A wait operation, attach process, or yield was attempted from a DPC routine.
This is an illegal operation and the stack track will lead to the offending
code and original DPC routine.
Arguments:
Arg1: fffff80003063cc0, Original thread which is the cause of the failure
Arg2: fffffa800a94b3a0, New thread
Arg3: 0000000000000000, Stack address of the original thread
Arg4: 0000000000000000

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

FAULTING_THREAD: fffff80003063cc0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xB8

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff80002eddfb4 to fffff80002edabc0

STACK_TEXT:
fffff880`08ba98b8 fffff800`02eddfb4 : 00000000`000000b8 fffff800`03063cc0 fffffa80`0a94b3a0 00000000`00000000 : nt!KeBugCheckEx
fffff880`08ba98c0 00000000`000000b8 : fffff800`03063cc0 fffffa80`0a94b3a0 00000000`00000000 00000000`00000000 : nt!SwapContext_PatchXRstor+0x120
fffff880`08ba98c8 fffff800`03063cc0 : fffffa80`0a94b3a0 00000000`00000000 00000000`00000000 00000000`00000400 : 0xb8
fffff880`08ba98d0 fffffa80`0a94b3a0 : 00000000`00000000 00000000`00000000 00000000`00000400 fffffa80`0a94b3a0 : nt!KiInitialThread
fffff880`08ba98d8 00000000`00000000 : 00000000`00000000 00000000`00000400 fffffa80`0a94b3a0 fffff800`02edda8a : 0xfffffa80`0a94b3a0

STACK_COMMAND: .thread 0xfffff80003063cc0 ; kb

FOLLOWUP_IP:
nt!SwapContext_PatchXRstor+120
fffff800`02eddfb4 c3 ret

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!SwapContext_PatchXRstor+120

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 521ea035

FAILURE_BUCKET_ID: X64_0xB8_nt!SwapContext_PatchXRstor+120

BUCKET_ID: X64_0xB8_nt!SwapContext_PatchXRstor+120

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

neieus · Mar 1, 2014

How many sticks of RAM do you have installed? I would try removing them and testing one at a time and in different slots if you can.

TheMooMooTV · Mar 1, 2014

I agree, that is definitely a memory issue. I would run memtest86 for at least 8 passes. Test each RAM stick individually, if one stick has any errors try another stick in the same DIMM slot as the slot itself could be faulty. let us know the results.

I3LiNdSp0t · Mar 2, 2014

My specs are under my Avatar/Profile, just like most have and you too =D

I have 2x 4GB DDR3-1600... I replaced the pair of HP I had before with this LP version, as the HP were giving me the run around with BSOD all over the place [See OP] and were causing my BSODs.

The most common one I get is the IRQL_NO_LESS_OR_EQUAL sumtin sumtin with either the ntokrnl.exe or a Driver Fault. And with the old RAM, it was a VISTA_DRIVER and now its a W7 one... Pretty confusing imho =)

When I get back home tonight, I will see if I can get MemTest to run and let it go overnight, one stick atta time.

Thnx Both for replying!

PeaCe

TheMooMooTV · Mar 2, 2014

ntoskrnl.exe is not the cause unless you have a virus disguising itself as ntoskrnl.exe
This file is the kernel, without this file your system will not boot. Do not download 'fixes' for system files, the best thing to do if your system is unstable is perform the windows system file checker. To perform this you must go into the command prompt and type "sfc /scannow". If it doesn't work then you will have to repair windows via the installation disc.

Your IRQL_NO_LESS_OR_EQUAL generally indicates a device driver has tried to access a memory memory address that it didn't have permission to, because the driver was running in kernel mode it generated a STOP error. What are you doing at the time of the crash?

I3LiNdSp0t · Mar 2, 2014

I do a sfc scan after every BSOD I have and they are 100% each time. I did swap the sticks and slots, but they still come up.

Besides doing MemTest upcoming night, I already replaced the RAM because they were faulty. What are the chances that it's the same problem or maybe settings I need to change or what else could cause this besides RAM? Mobo ram slots faulty?

The BSOD are random, the last one was on Idle, it happens at moments whether or not I am doing something or nothing. It's really frustrating tbh =(

Some came from internet connection while downloading, I even had one crashing on the Firefox exe, but that was before the fresh install and ram replacement. So they occure random and can happen at anytime.

I know a bit about software and pc's, but I cannot find any type of action that causes the BSOD/memory corruption, that's how random they are.

Here's another today @12.04:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000b9c958, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff88004387020, address which referenced memory

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

*** WARNING: Unable to verify timestamp for Rt64win7.sys
*** ERROR: Module load completed but symbols could not be loaded for Rt64win7.sys

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800030ba100
GetUlongFromAddress: unable to read from fffff800030ba1c0
0000000000b9c958 Nonpaged pool

CURRENT_IRQL: 2

FAULTING_IP:
Rt64win7+d1020
fffff880`04387020 480fc311 movnti qword ptr [rcx],rdx

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TAG_NOT_DEFINED_c000000f: FFFFF80000BA2FB0

TRAP_FRAME: fffff80000b9c6e0 -- (.trap 0xfffff80000b9c6e0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff80000b9c958 rbx=0000000000000000 rcx=0000000000b9c958
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88004387020 rsp=fffff80000b9c878 rbp=0000000000000004
r8=0000000000000038 r9=0004040404040404 r10=00000000000316c5
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
Rt64win7+0xd1020:
fffff880`04387020 480fc311 movnti qword ptr [rcx],rdx ds:00000000`00b9c958=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002e82169 to fffff80002e82bc0

STACK_TEXT:
fffff800`00b9c598 fffff800`02e82169 : 00000000`0000000a 00000000`00b9c958 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff800`00b9c5a0 fffff800`02e80de0 : fffffa80`0722c100 00000000`00000001 00000000`00000000 fffffa80`0953e000 : nt!KiBugCheckDispatch+0x69
fffff800`00b9c6e0 fffff880`04387020 : fffff880`042d0043 00000000`00000000 fffffa80`10bcba50 fffffa80`10bcba50 : nt!KiPageFault+0x260
fffff800`00b9c878 fffff880`042d0043 : 00000000`00000000 fffffa80`10bcba50 fffffa80`10bcba50 fffff880`016692c0 : Rt64win7+0xd1020
fffff800`00b9c880 00000000`00000000 : fffffa80`10bcba50 fffffa80`10bcba50 fffff880`016692c0 00000000`00000001 : Rt64win7+0x1a043

STACK_COMMAND: kb

FOLLOWUP_IP:
Rt64win7+d1020
fffff880`04387020 480fc311 movnti qword ptr [rcx],rdx

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: Rt64win7+d1020

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Rt64win7

IMAGE_NAME: Rt64win7.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 52b114c6

FAILURE_BUCKET_ID: X64_0xD1_Rt64win7+d1020

BUCKET_ID: X64_0xD1_Rt64win7+d1020

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

neieus · Mar 2, 2014

It's totally possible a RAM slot on the board could be bad. When testing using 1 RAM module at a time do you allow Windows to run and work as normal? If so for how long? Did you still experience a crash? The thing is if you're just removing all memory and starting up windows letting it run for a few minutes then shutting it down to swap or replace the memory then that's not a good enough test. The reason the programs are random is because the program could exist in a different part of the memory each time windows crashes. Also if for any reason you are overclocking while testing this you will need to restore to defaults to insure a stable system.

I3LiNdSp0t · Mar 2, 2014

I had the RAM in the same slots until you said to swap and/or run 1 at a time. So I changed slots and haven't touched them since. 1st they were in A1 and B1, now they are in A2 and B2.

I do not OC, never done that, so not even trying either.

Here is a screenshot of the times and dates of the BSODs since March 1st: http://prntscr.com/2x60bv

Windows itself runs great sofar I can tell and since the SFC scans come up empty, I cannot see Windows being corrupted somewhere, but I'm no expert xD.

It seems when I download with uTorrent for example, it crashed twice, once with TCIip or something and the other with that last report -> rt64win7.sys

I have now shutdown some more services and BG programs and see what happens.

neieus · Mar 2, 2014

Well rt64win7.sys is a Realtek Network card driver. Check to make sure you have the newest version drive and if you do try downgrading your driver instead.

I3LiNdSp0t · Mar 2, 2014

neieus :

According to Windows, DriverBooster and Realtek I have the latest driver available.

If I want to downgrade, I need to remove the old one completely and then install an older one? Because otherwise it won't allow me to change it as it's telling me I have the latest one.

neieus · Mar 2, 2014

Correct you would need to remove the old one first

I3LiNdSp0t · Mar 2, 2014

And there it goes again, I had some good hopes...

It is stuck on Collecting Data for crash dump atm.

I rebooted in Safe Mode now and will leave it on until I get back.

BSOD minidump analysis

Reputable

Distinguished

Reputable

Distinguished

Reputable

Distinguished

Reputable

Reputable

Reputable

Distinguished

Honorable

Reputable

Honorable

Reputable

Distinguished

Reputable

Distinguished

Reputable

Distinguished

Reputable

Share this page