Windows 7 Forums
Welcome to Windows 7 Forums. Our forum is dedicated to helping you find support and solutions for any problems regarding your Windows 7 PC be it Dell, HP, Acer, Asus or a custom build. We also provide an extensive Windows 7 tutorial section that covers a wide range of tips and tricks.


Windows 7: Frequent BSOD with massive slowdown, possibly caused by ntoskrnl.exe


25 Feb 2012   #1

Windows 7 Home Premium x64
 
 
Frequent BSOD with massive slowdown, possibly caused by ntoskrnl.exe

Hello all. My computer with Windows 7 Home Edition x64 has been getting frequent BSOD as well as being super slow and unresponsive. I have attached a copy of the recent dump files hoping to find anything out as to why this is happening. I am appreciative for any input I receive.

My System SpecsSystem Spec
.

25 Feb 2012   #2

Windows 7 Ultimate x64
 
 

Hello, welcome to SevenForums!

Dumps are blaming pool corruption and storport.sys, storport.sys is highly unlikely as something is causing THAT itself to crash. Few things, you have SPTD.sys, which is a driver that is part of Daemon Tools. Please uninstall Daemon Tools if you haven't already, restart, and then run DuplexSecure's SPTD Uninstaller / Remover, and then restart once again.

Another thing in one of the dump files, I have to ask if this means that this is the process fault in a thread, but regardless....

Quote:
Unable to load image \SystemRoot\System32\Drivers\aswSP.SYS, Win32 error 0n2
*** WARNING: Unable to verify timestamp for aswSP.SYS
*** ERROR: Module load completed but symbols could not be loaded for aswSP.SYS
Probably caused by : Pool_Corruption ( nt!ExDeferredFreePool+cbb )
aswSP.sys (avast! Self Protection Driver)

I would recommend uninstalling Avast temporarily and install Microsoft Security Essentials just for testing, it is also known to sometimes cause issues with Windows 7 and cause BSODs.

Quote:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000003, the pool freelist is corrupt.
Arg2: fffffa8003e59320, the pool entry being checked.
Arg3: fffffa8003e59320, the read back flink freelist value (should be the same as 2).
Arg4: 0001010001e59320, the read back blink freelist value (should be the same as 2).

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


BUGCHECK_STR: 0x19_3

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff800035ae70f to fffff80003480c40

STACK_TEXT:
fffff880`07628e78 fffff800`035ae70f : 00000000`00000019 00000000`00000003 fffffa80`03e59320 fffffa80`03e59320 : nt!KeBugCheckEx
fffff880`07628e80 fffff800`035b01a1 : fffff880`07629100 fffffa80`0384cc60 00000000`00000000 65726370`00000000 : nt!ExDeferredFreePool+0xcbb
fffff880`07628f10 fffff880`04712e84 : 00000000`00000002 fffffa80`0621ba80 00000000`65726370 00000000`00000052 : nt!ExFreePoolWithTag+0x411
fffff880`07628fc0 00000000`00000002 : fffffa80`0621ba80 00000000`65726370 00000000`00000052 00000000`00000000 : aswSP+0x29e84
fffff880`07628fc8 fffffa80`0621ba80 : 00000000`65726370 00000000`00000052 00000000`00000000 00000000`00000000 : 0x2
fffff880`07628fd0 00000000`65726370 : 00000000`00000052 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffffa80`0621ba80
fffff880`07628fd8 00000000`00000052 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x65726370
fffff880`07628fe0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`05872df0 : 0x52


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExDeferredFreePool+cbb
fffff800`035ae70f cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!ExDeferredFreePool+cbb

FOLLOWUP_NAME: Pool_corruption

IMAGE_NAME: Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MODULE_NAME: Pool_Corruption

FAILURE_BUCKET_ID: X64_0x19_3_nt!ExDeferredFreePool+cbb

BUCKET_ID: X64_0x19_3_nt!ExDeferredFreePool+cbb

Followup: Pool_corruption

BugCheck A, {fffffa880638c6d8, 2, 0, fffff800039f43da}

Unable to load image \SystemRoot\System32\Drivers\sptd.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for sptd.sys
*** ERROR: Module load completed but symbols could not be loaded for sptd.sys
Probably caused by : storport.sys ( storport!RaUnitStartIo+2e1 )

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

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: fffffa880638c6d8, 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: fffff800039f43da, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800036b8100
fffffa880638c6d8

CURRENT_IRQL: 2

FAULTING_IP:
hal!HalpDmaNextContiguousPiece+66
fffff800`039f43da 4c3954ee30 cmp qword ptr [rsi+rbp*8+30h],r10

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffff880031fb690 -- (.trap 0xfffff880031fb690)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000c00 rbx=0000000000000000 rcx=0000000000000400
rdx=0000000000000400 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800039f43da rsp=fffff880031fb828 rbp=00000000ffff476b
r8=0000000000000400 r9=000fffffffff476b r10=00000000000fffff
r11=fffffa80040b5ce0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
hal!HalpDmaNextContiguousPiece+0x66:
fffff800`039f43da 4c3954ee30 cmp qword ptr [rsi+rbp*8+30h],r10 ds:0001:00000007`fffa3b88=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800034851e9 to fffff80003485c40

STACK_TEXT:
fffff880`031fb548 fffff800`034851e9 : 00000000`0000000a fffffa88`0638c6d8 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`031fb550 fffff800`03483e60 : 00000000`00000000 fffffa80`05a80860 00000000`000000b0 fffff880`0390a100 : nt!KiBugCheckDispatch+0x69
fffff880`031fb690 fffff800`039f43da : fffffa80`063e8b50 fffff8a0`0211fc00 fffff800`039f4524 fffff880`0390a100 : nt!KiPageFault+0x260
fffff880`031fb828 fffff800`039f4524 : fffff880`0390a100 fffffa80`040b5ce0 fffffa80`040b6f00 00000000`00000000 : hal!HalpDmaNextContiguousPiece+0x66
fffff880`031fb840 fffff800`039f74fb : fffff880`0390a100 fffffa80`040b5ce0 fffffa80`063e8b50 fffffa80`00000000 : hal!HalpDmaMapScatterTransfer+0x34
fffff880`031fb890 fffff800`039f7472 : fffff880`0390a100 fffff880`0390a0f8 00000000`00000400 00000000`00000000 : hal!HalpMapTransfer+0x7b
fffff880`031fb920 fffff800`039f694f : 00000000`00000000 fffff800`039f3fb9 00000000`00000000 00000000`00000001 : hal!IoMapTransfer+0x8e
fffff880`031fb960 fffff800`039f713d : fffffa80`040b6060 fffffa80`040b5ce0 00000000`00000000 00000000`00000000 : hal!HalpAllocateAdapterCallback+0xc7
fffff880`031fba00 fffff800`039f671f : fffff880`0390a0b8 00000000`00000400 fffffa80`040b5ce0 fffffa80`063e8b50 : hal!HalAllocateAdapterChannel+0x101
fffff880`031fba40 fffff880`0112ded1 : fffff880`0390a010 fffffa80`05534420 00000000`000000a0 fffffa80`05534498 : hal!HalBuildScatterGatherList+0x2f3
fffff880`031fbab0 fffff880`011312ce : fffffa80`00000001 fffffa80`03a6e1d0 fffffa80`040beb10 fffffa80`040b61b0 : storport!RaUnitStartIo+0x2e1
fffff880`031fbb30 fffff880`0112e553 : fffffa80`00000000 fffff880`000000fc fffff880`00fccb50 fffffa80`040b6128 : storport! ?? ::FNODOBFM::`string'+0x1a2e
fffff880`031fbc10 fffff880`00e7b570 : fffffa80`03697000 00000000`00000000 fffffa80`040b6100 fffff880`047417f2 : storport!RaidpAdapterDpcRoutine+0x53
fffff880`031fbc50 fffffa80`03697000 : 00000000`00000000 fffffa80`040b6100 fffff880`047417f2 00000000`00000010 : sptd+0x46570
fffff880`031fbc58 00000000`00000000 : fffffa80`040b6100 fffff880`047417f2 00000000`00000010 00000000`00000246 : 0xfffffa80`03697000


STACK_COMMAND: kb

FOLLOWUP_IP:
storport!RaUnitStartIo+2e1
fffff880`0112ded1 3d230000c0 cmp eax,0C0000023h

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: storport!RaUnitStartIo+2e1

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: storport

IMAGE_NAME: storport.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a55f

FAILURE_BUCKET_ID: X64_0xA_storport!RaUnitStartIo+2e1

BUCKET_ID: X64_0xA_storport!RaUnitStartIo+2e1

Followup: MachineOwner

BugCheck A, {fffffa88039ac180, 2, 0, fffff800034113da}

Unable to load image \SystemRoot\System32\Drivers\sptd.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for sptd.sys
*** ERROR: Module load completed but symbols could not be loaded for sptd.sys
Probably caused by : storport.sys ( storport!RaUnitStartIo+2e1 )

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

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: fffffa88039ac180, 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: fffff800034113da, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80003707100
fffffa88039ac180

CURRENT_IRQL: 2

FAULTING_IP:
hal!HalpDmaNextContiguousPiece+66
fffff800`034113da 4c3954ee30 cmp qword ptr [rsi+rbp*8+30h],r10

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffff880031fb5b0 -- (.trap 0xfffff880031fb5b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000001000
rdx=0000000000001000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800034113da rsp=fffff880031fb748 rbp=00000000fffffec2
r8=0000000000001000 r9=000ffffffffffec2 r10=00000000000fffff
r11=fffffa80040d2ea0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
hal!HalpDmaNextContiguousPiece+0x66:
fffff800`034113da 4c3954ee30 cmp qword ptr [rsi+rbp*8+30h],r10 ds:00000007`fffff640=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800034d41e9 to fffff800034d4c40

STACK_TEXT:
fffff880`031fb468 fffff800`034d41e9 : 00000000`0000000a fffffa88`039ac180 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`031fb470 fffff800`034d2e60 : fffffa80`036f0230 fffff880`00ef7c98 fffffa80`0574da10 fffff880`0390f100 : nt!KiBugCheckDispatch+0x69
fffff880`031fb5b0 fffff800`034113da : fffffa80`039acb40 fffff8a0`05678000 fffff800`03411524 fffff880`0390f100 : nt!KiPageFault+0x260
fffff880`031fb748 fffff800`03411524 : fffff880`0390f100 fffffa80`040d2ea0 fffffa80`040d0be0 00000000`00000000 : hal!HalpDmaNextContiguousPiece+0x66
fffff880`031fb760 fffff800`034144fb : fffff880`0390f100 fffffa80`040d2ea0 fffffa80`039acb40 00000000`00000000 : hal!HalpDmaMapScatterTransfer+0x34
fffff880`031fb7b0 fffff800`03414472 : fffff880`0390f100 fffff880`0390f0f8 00000000`00001000 00000000`00000000 : hal!HalpMapTransfer+0x7b
fffff880`031fb840 fffff800`0341394f : 00000000`00000000 fffff800`03410fb9 00000000`00000000 00000000`00000001 : hal!IoMapTransfer+0x8e
fffff880`031fb880 fffff800`0341413d : fffffa80`040d1060 fffffa80`040d2ea0 00000000`00000000 ffffffff`00000000 : hal!HalpAllocateAdapterCallback+0xc7
fffff880`031fb920 fffff800`0341371f : fffff880`0390f0b8 00000000`00001000 fffffa80`040d2ea0 fffffa80`039acb40 : hal!HalAllocateAdapterChannel+0x101
fffff880`031fb960 fffff880`00c01ed1 : fffff880`0390f010 fffffa80`07031650 00000000`000000a0 fffffa80`070316c8 : hal!HalBuildScatterGatherList+0x2f3
fffff880`031fb9d0 fffff880`00c04df7 : 00000000`00000001 fffffa80`07096370 00000000`00000000 00000000`00000000 : storport!RaUnitStartIo+0x2e1
fffff880`031fba50 fffff880`00c02976 : fffffa80`040db1b0 00000000`00000000 00000000`000000fb fffffa80`040d1128 : storport! ?? ::FNODOBFM::`string'+0x1523
fffff880`031fbb30 fffff880`00c02553 : fffffa80`03697000 fffff880`000000fb fffffa80`04d97050 00000000`00000000 : storport!RaidUnitCompleteRequest+0x3a6
fffff880`031fbc10 fffff880`0106a570 : fffffa80`03697000 00000000`00000000 fffffa80`040d1100 fffff880`047d27f2 : storport!RaidpAdapterDpcRoutine+0x53
fffff880`031fbc50 fffffa80`03697000 : 00000000`00000000 fffffa80`040d1100 fffff880`047d27f2 00000000`00000010 : sptd+0x46570
fffff880`031fbc58 00000000`00000000 : fffffa80`040d1100 fffff880`047d27f2 00000000`00000010 00000000`00000246 : 0xfffffa80`03697000


STACK_COMMAND: kb

FOLLOWUP_IP:
storport!RaUnitStartIo+2e1
fffff880`00c01ed1 3d230000c0 cmp eax,0C0000023h

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: storport!RaUnitStartIo+2e1

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: storport

IMAGE_NAME: storport.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a55f

FAILURE_BUCKET_ID: X64_0xA_storport!RaUnitStartIo+2e1

BUCKET_ID: X64_0xA_storport!RaUnitStartIo+2e1

Followup: MachineOwner

BugCheck A, {90, 2, 0, fffff800034e8f35}

Probably caused by : ntkrnlmp.exe ( nt!KiCommitThreadWait+1d5 )

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

1: 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: 0000000000000090, 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: fffff800034e8f35, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80003716100
0000000000000090

CURRENT_IRQL: 2

FAULTING_IP:
nt!KiCommitThreadWait+1d5
fffff800`034e8f35 488bbb90000000 mov rdi,qword ptr [rbx+90h]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: AvastSvc.exe

TRAP_FRAME: fffff8800a1bf3a0 -- (.trap 0xfffff8800a1bf3a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000ffef0000 rbx=0000000000000000 rcx=fffff8800a1bf4f0
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800034e8f35 rsp=fffff8800a1bf530 rbp=0000000000000000
r8=fffffa800632fbb8 r9=0000000000000000 r10=fffffffffffffffd
r11=00000000000f0001 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
nt!KiCommitThreadWait+0x1d5:
fffff800`034e8f35 488bbb90000000 mov rdi,qword ptr [rbx+90h] ds:00000000`00000090=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800034e31e9 to fffff800034e3c40

STACK_TEXT:
fffff880`0a1bf258 fffff800`034e31e9 : 00000000`0000000a 00000000`00000090 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`0a1bf260 fffff800`034e1e60 : fffff680`00048c78 fffff800`034e68a4 00000000`00000001 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`0a1bf3a0 fffff800`034e8f35 : fffffa80`062fe060 fffffa80`062fe060 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x260
fffff880`0a1bf530 fffff800`034eb74f : 90e00000`7a3f1867 fffff800`03667c80 fffff6fc`00000000 fffffa80`00000000 : nt!KiCommitThreadWait+0x1d5
fffff880`0a1bf5c0 fffff880`0123dd46 : fffff880`01233300 fffff880`00000000 fffff6fc`40049500 00000000`00000000 : nt!KeWaitForSingleObject+0x19f
fffff880`0a1bf660 fffff880`0122c684 : fffffa80`03b9c700 fffff880`00dc1d00 fffffa80`041ea930 fffff880`0a1bf701 : Ntfs!NtfsVolumeDasdIo+0x19a
fffff880`0a1bf710 fffff880`0122ca68 : fffffa80`03b9c700 fffffa80`039beaf0 fffff880`0a1bf801 fffffa80`03a06c00 : Ntfs!NtfsCommonRead+0x1e58
fffff880`0a1bf8b0 fffff880`00db4bcf : fffffa80`039bee90 fffffa80`039beaf0 fffffa80`03a06c30 00000000`00000000 : Ntfs!NtfsFsdRead+0x1b8
fffff880`0a1bf960 fffff880`00db36df : fffffa80`041dade0 00000000`00000001 fffffa80`041dad00 fffffa80`039beaf0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880`0a1bf9f0 fffff800`037ec21b : 00000000`00000000 fffffa80`06dae2d0 00000000`00000001 fffffa80`039beaf0 : fltmgr!FltpDispatch+0xcf
fffff880`0a1bfa50 fffff800`037cdb63 : fffffa80`06dae2d0 fffffa80`06dae2d0 fffffa80`06dae2d0 fffffa80`00000001 : nt!IopSynchronousServiceTail+0xfb
fffff880`0a1bfac0 fffff800`034e2ed3 : 00000000`00001548 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtReadFile+0x631
fffff880`0a1bfbb0 00000000`73942e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0918f0b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x73942e09


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiCommitThreadWait+1d5
fffff800`034e8f35 488bbb90000000 mov rdi,qword ptr [rbx+90h]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!KiCommitThreadWait+1d5

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

FAILURE_BUCKET_ID: X64_0xA_nt!KiCommitThreadWait+1d5

BUCKET_ID: X64_0xA_nt!KiCommitThreadWait+1d5

Followup: MachineOwner

My System SpecsSystem Spec
Reply

 Frequent BSOD with massive slowdown, possibly caused by ntoskrnl.exe




Thread Tools



Similar help and support threads for2: Frequent BSOD with massive slowdown, possibly caused by ntoskrnl.exe
Thread Forum
Constant BSOD caused possibly by ntoskrnl.exe BSOD Help and Support
frequent BSOD caused by ntoskrnl.exe and many others on windows 7 BSOD Help and Support
BSOD possibly caused by dtsoftbus01 on new build BSOD Help and Support
Massive Slowdown in all games Gaming
Solved BSoD While Scanning PS With Avast, Possibly Caused by Atikmdag.sys BSOD Help and Support
win 7 64bit clean install then massive slowdown Performance & Maintenance
BSOD possibly caused by Zune software BSOD Help and Support

Our Sites

Site Links

About Us

Find Us

Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

Designer Media Ltd

All times are GMT -5. The time now is 02:08 AM.
Twitter Facebook Google+



Windows 7 Forums

Seven Forums Android App Seven Forums IOS App
  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33