Windows 10 Freezing

HyperHenry said:
I found this in the SMART Values on your HDD. The normal G-Sense Rate is 58. This indicates that the head mechanism may be failing.

Attribute name:
G-sense error rate

Real value: 2,435

Current: 99

Worst: 99


Threshold: 0


Raw Value: 0000000983
Click to expand...

It seems more like a counter for how many times the drive's shocking and moving from its place. It doesn't seem to be an attribute that determines whether or not the drive is physically failing, the drive in my laptop should've failed a long time ago if it was.
See ZAR - Quick guide to understanding S.M.A.R.T. information & S.M.A.R.T. - Wikipedia
 
This is a SMART value I've never seen before so I Googled it and what I found said that a high G-Sense Error Rate was an indication of a possible failure. The other values all looked ok on the Speccy report. I'd suggest downloading Chrystal Disk Info http://CrystalDiskInfo7_5_2.zip - CrystalDiskInfo - OSDN and taking a screenshot of the Smart Values. The symptoms would be consistant with a failing drive.
 
The values that CDI reported are identical to Speccy's. I personally doubt that it's the HDD failing that's causing these symptoms as the OS is installed on my SSD, and these freezes typically occur when the HDD is not active. Moreover, tightening the mount that keeps it fastened in the bay has stopped the G-sense errors from accumulating, so I think I can safely write that off as the cause.

I can also eliminate XMP and this HDMI cable as being the culprits, as I just had another freeze with that disabled/unplugged. This feels to me like a software issue given that before the freezes occur, the mouse cursor turns into a "busy" wheel, as though it's trying to do something. At one point, I was able to get the system to avoid freezing by simply tapping the power button (Forcing all processes to terminate). But what rogue process could be causing this, I don't know. I suspect that it might be Autodesk Inventor, as that program's child process amijm.exe has given me trouble in the past (Looking back on it, these freezes did only start occurring after I started using it too...), but I really can't say anything conclusively right now. I wish I had a log I could send, but none was recorded this time either. :\

Maybe I'll try running the computer with SysInternal's Process Monitor always active. At least then I'll know exactly what the computer was doing when it froze.
 
What do you mean by that, Robot? Also, I suppose that wasn't the answer either as I just had another freeze. This one did leave a Watchdog report with the following:

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

PDC_LOCK_WATCHDOG_LIVEDUMP (17c)
A thread has been holding the PDC lock for too long
(This code can never be used for a real bugcheck.)
Arguments:
Arg1: ffffd40e79144040, The thread holding the PDC lock.
Arg2: 0000000000002710, Lock watchdog timeout in milliseconds.
Arg3: 0000000000000000, Reserved.
Arg4: 0000000000000000, Reserved.

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


KEY_VALUES_STRING: 1


TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 401

BUILD_VERSION_STRING: 16299.15.amd64fre.rs3_release.170928-1534

SYSTEM_MANUFACTURER: MSI

SYSTEM_PRODUCT_NAME: MS-7885

SYSTEM_SKU: Default string

SYSTEM_VERSION: 1.0

BIOS_VENDOR: American Megatrends Inc.

BIOS_VERSION: 1.D0

BIOS_DATE: 07/15/2016

BASEBOARD_MANUFACTURER: MSI

BASEBOARD_PRODUCT: X99A SLI PLUS(MS-7885)

BASEBOARD_VERSION: 1.0

DUMP_TYPE: 1

DUMP_FILE_ATTRIBUTES: 0x10
Live Generated Dump

BUGCHECK_P1: ffffd40e79144040

BUGCHECK_P2: 2710

BUGCHECK_P3: 0

BUGCHECK_P4: 0

CPU_COUNT: c

CPU_MHZ: d48

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 4f

CPU_STEPPING: 1

CPU_MICROCODE: 6,4f,1,0 (F,M,S,R) SIG: B00001D'00000000 (cache) B00001D'00000000 (init)

DEFAULT_BUCKET_ID: WINBLUE_LIVE_KERNEL_DUMP

BUGCHECK_STR: 0x17C

PROCESS_NAME: System

CURRENT_IRQL: 0

ANALYSIS_SESSION_HOST: DESKTOP-H97F1JD

ANALYSIS_SESSION_TIME: 03-09-2018 20:47:31.0822

ANALYSIS_VERSION: 10.0.17074.1002 amd64fre

LAST_CONTROL_TRANSFER: from fffff8008822f96d to fffff8008822ab2e

STACK_TEXT:
ffffbb8d`10ee66b0 fffff800`8822f96d : ffffffff`ffffffff 00000000`008a6de3 00000000`008a6de3 00000000`0001921d : nt!IopLiveDumpEndMirroringCallback+0x7e
ffffbb8d`10ee6700 fffff800`8822a7c7 : ffffbb8d`10ee6818 fffff800`00000008 00000043`00000000 00000000`00000000 : nt!MmDuplicateMemory+0xcc1
ffffbb8d`10ee67e0 fffff800`884b949d : ffffd40e`7a8e9d70 ffffd40e`7a8e9d70 ffffbb8d`10ee6aa8 ffffbb8d`10ee6aa8 : nt!IopLiveDumpCaptureMemoryPages+0x7f
ffffbb8d`10ee68a0 fffff800`884ad57d : 00000000`00000000 ffffbe80`ceac4330 ffffbe80`dc73f290 ffffbe80`ceac4330 : nt!IoCaptureLiveDump+0x289
ffffbb8d`10ee6a40 fffff800`884adc88 : ffffffff`80003038 00000000`00000000 00000000`00000000 00000000`00002710 : nt!DbgkpWerCaptureLiveFullDump+0x12d
ffffbb8d`10ee6aa0 fffff800`884ad3db : 00000000`00000002 00000000`00000000 00000000`00000000 00000000`0000017c : nt!DbgkpWerProcessPolicyResult+0x30
ffffbb8d`10ee6ad0 fffff80b`86a9533d : ffffd40e`7c9a1040 fffff80b`86a95300 ffffd40e`7109c1b0 fffff80b`86a8d1e8 : nt!DbgkWerCaptureLiveKernelDump+0x19b
ffffbb8d`10ee6b20 fffff800`87e3f4d5 : ffffd40e`7109c1b0 ffffd40e`7c9a1000 ffffd40e`7109c100 fffff80b`86e74150 : pdc!PdcpLockWatchdogWorkerRoutine+0x3d
ffffbb8d`10ee6b80 fffff800`87f1ab87 : ffffd40e`7c9a1040 00000000`00000080 ffffd40e`710dd440 ffffd40e`7c9a1040 : nt!ExpWorkerThread+0xf5
ffffbb8d`10ee6c10 fffff800`87f80be6 : ffffab80`37cc0180 ffffd40e`7c9a1040 fffff800`87f1ab40 00000000`00000246 : nt!PspSystemThreadStartup+0x47
ffffbb8d`10ee6c60 00000000`00000000 : ffffbb8d`10ee7000 ffffbb8d`10ee1000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


THREAD_SHA1_HASH_MOD_FUNC: 3fe1bb7f3aca04cfc6afaacd146c5e9a5a6ac87e

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 92322e5c8b06566a14ef7104e178990732436af1

THREAD_SHA1_HASH_MOD: 6bd97e886c29d15bb599e90f8e17dc9b2f30e4a6

FOLLOWUP_IP:
pdc!PdcpLockWatchdogWorkerRoutine+3d
fffff80b`86a9533d 4533c0 xor r8d,r8d

FAULT_INSTR_CODE: 48c03345

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: pdc!PdcpLockWatchdogWorkerRoutine+3d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: pdc

IMAGE_NAME: pdc.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4003a619

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: 3d

FAILURE_BUCKET_ID: LKD_0x17C_pdc!PdcpLockWatchdogWorkerRoutine

BUCKET_ID: LKD_0x17C_pdc!PdcpLockWatchdogWorkerRoutine

PRIMARY_PROBLEM_CLASS: LKD_0x17C_pdc!PdcpLockWatchdogWorkerRoutine

TARGET_TIME: 2018-03-10T04:37:24.000Z

OSBUILD: 16299

OSSERVICEPACK: 0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 784

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS Personal

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2018-02-09 20:34:33

BUILDDATESTAMP_STR: 170928-1534

BUILDLAB_STR: rs3_release

BUILDOSVER_STR: 10.0.16299.15.amd64fre.rs3_release.170928-1534

ANALYSIS_SESSION_ELAPSED_TIME: 53d

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:lkd_0x17c_pdc!pdcplockwatchdogworkerroutine

FAILURE_ID_HASH: {abbfa659-7794-4fad-eb25-b156cbce98a0}

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


I really do not understand what could be causing this. This time it occurred while the PC was more or less idle and I simply tried running a speed test.
 
Can anyone please try and interpret these crash dumps? It says that it was "Probably caused by : pdc.sys". What is this?
 
From an elevated command prompt please try running the following commands:

Code: 
cd \
powercfg /spr

It should generate a report at the root of the system drive named sleepstudy-report.html which I'm hoping might show something useful.
 
I'm not sure the live dumps are getting created due to what's causing the system to freeze. The dumps might be getting generated when the system is told to shutdown; presumably when you're hitting the power button. Oddly, it looks like it's getting stuck waiting on a synchronization object and after a certain amount of time does a live kernel dump due to a watchdog timeout. If I'm correct it would suggest the system might not be completely locked when the freeze happens and you might be able to generate a manual dump which should be more reflective of the state of the system at the time of the problem.

Please try configuring your system according to the instruction here, restart the system, and then next time the system freezes hold down the Ctrl key and then tap ScrLk twice. Hopefully that will crash the box and we might have a more useful dump file.

Also, it looks like there might be a more up to date Xbox Wireless Adapter for Windows driver than the one you're using. If you sort the list on this page by the Last Updated column the top download should be the one you'd want. There's nothing I see to indicate it's the problem but some of what you've said suggests it could be a network issue so I think it would be worth a try.
​
 
Very interesting. That might explain why the dumps are not always recorded and how I can sometimes pull it out of a freeze if I tap the power button before the cursor locks up. I'll make those changes and update you if another crash occurs.
 
Yes, thanks for providing your dump file settings. Everything seems to be the default.

Code: 
[COLOR=#ff0000]BugCheck 17C[/COLOR], {[COLOR=#008000]ffffd40e79144040[/COLOR], 2710, 0, 0}

Probably caused by : pdc.sys ( pdc!PdcpLockWatchdogWorkerRoutine+3d )

The crash seems to have occurred when exiting standby mode. The first parameter of the bugcheck is the thread which contains the callstack before the crash. There isn't much useful information here. This bugcheck is very difficult since it is poorly documented, with every little information provided by Microsoft, so there's going to be some educated guesses involved here unfortunately.

Code: 
0: kd> [COLOR=#008000]knL[/COLOR]
 # Child-SP          RetAddr           Call Site
00 ffffbb8d`10ee66b0 fffff800`8822f96d nt!IopLiveDumpEndMirroringCallback+0x7e
01 ffffbb8d`10ee6700 fffff800`8822a7c7 nt!MmDuplicateMemory+0xcc1
02 ffffbb8d`10ee67e0 fffff800`884b949d nt!IopLiveDumpCaptureMemoryPages+0x7f
03 ffffbb8d`10ee68a0 fffff800`884ad57d nt!IoCaptureLiveDump+0x289
04 ffffbb8d`10ee6a40 fffff800`884adc88 nt!DbgkpWerCaptureLiveFullDump+0x12d
05 ffffbb8d`10ee6aa0 fffff800`884ad3db nt!DbgkpWerProcessPolicyResult+0x30
06 ffffbb8d`10ee6ad0 fffff80b`86a9533d nt!DbgkWerCaptureLiveKernelDump+0x19b
07 ffffbb8d`10ee6b20 fffff800`87e3f4d5 [COLOR=#ff0000]pdc!PdcpLockWatchdogWorkerRoutine+0x3d[/COLOR] << System detects that Power IRPs are taking too long to process
08 ffffbb8d`10ee6b80 fffff800`87f1ab87 nt!ExpWorkerThread+0xf5
09 ffffbb8d`10ee6c10 fffff800`87f80be6 nt!PspSystemThreadStartup+0x47
0a ffffbb8d`10ee6c60 00000000`00000000 nt!KiStartSystemThread+0x16

Let's dump the current power state of the system using the !poaction debugger extension:

Code: 
0: kd> [COLOR=#008000]!poaction[/COLOR]
PopAction: fffff80088166820
  State..........: [COLOR=#ff0000]0 - Idle[/COLOR]
  Updates........: 0 
  Action.........: None
  Lightest State.: Unspecified
  Flags..........: 10000003 QueryApps|UIAllowed
  Irp minor......: ??
  System State...: Unspecified
  Hiber Context..: 0000000000000000

[COLOR=#0000cd]Allocated power irps[/COLOR] (PopIrpList - fffff80088166ee0)
  IRP: ffffd40e760c88a0 ([COLOR=#ff0000]wait-wake/S4[/COLOR]), PDO: ffffd40e73f1c060
  IRP: ffffd40e7525c940 (wait-wake/S4), PDO: ffffd40e75223620
  IRP: ffffd40e75245940 (wait-wake/S4), PDO: ffffd40e75251060
  IRP: ffffd40e752dfc10 (wait-wake/S4), PDO: ffffd40e75e14060
  IRP: ffffd40e76f3ec10 (wait-wake/S4), PDO: ffffd40e75157050
  IRP: ffffd40e753a1ab0 (wait-wake/S4), PDO: ffffd40e76eeda90
  IRP: ffffd40e753e9010 (wait-wake/S4), PDO: ffffd40e7539a060
  IRP: ffffd40e753908b0 (wait-wake/S4), PDO: ffffd40e75398060
  IRP: ffffd40e753e48b0 (wait-wake/S4), PDO: ffffd40e7538f060
  IRP: ffffd40e752bb010 (wait-wake/S4), PDO: ffffd40e7538e060
  IRP: ffffd40e76f2ac10 (wait-wake/S4), PDO: ffffd40e76e84060
  IRP: ffffd40e7558b740 (wait-wake/S4), PDO: ffffd40e75153050
  IRP: ffffd40e752e1c10 (wait-wake/S4), PDO: ffffd40e76ea63c0
  IRP: ffffd40e7b509700 (wait-wake/S4), PDO: ffffd40e76e98060

Irp worker threads (PopIrpThreadList - fffff80088165a10)
  THREAD: ffffd40e710c1040 (static)
  THREAD: ffffd40e710d7040 (static)

Broadcast in progress: FALSE

No Device State present

The current power state is 0 - Idle which is a standby mode implemented in operating systems Windows 8 and above. It allows the system to instantly 'wake' from sleep. Notice how Windows 8 machines used to boot very quickly from sleep? This is the Modern Standby mode implemented by Microsoft. It's the same power state which your smartphone would use when you press the power button.

Another important aspect is the currently queued power IRPs. Notice how they're all for the same power state transistion?

Let's grab the first IRP from the list, and see what is happening in it's stack:

Code: 
0: kd> [COLOR=#008000]!irp ffffd40e760c88a0[/COLOR]
Irp is active with 4 stacks 2 is current (= 0xffffd40e760c89b8)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), [COLOR=#0000cd]IRP_MN_WAIT_WAKE(0)[/COLOR]]
            0 e1 ffffd40e73f2ce40 00000000 fffff80b8707f3e0-ffffd40e74a431a0 Success Error Cancel [COLOR=#ff0000]pending[/COLOR]
           \Driver\ACPI    [COLOR=#ff0000]ndis!ndisWaitWakeIoCompletion[/COLOR]
            Args: 00000005 00000000 00000000 00000000
 [IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
            0 e0 ffffd40e74a43050 00000000 fffff80087f21890-ffffd40e73f50f00 Success Error Cancel 
*** ERROR: Module load completed but symbols could not be loaded for e1d65x64.sys
 \Driver\e1dexpress    nt!PopRequestCompletion
            Args: 00000005 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-ffffd40e73f50f00    

            Args: 00000000 00000000 00000000 00000000

Notice how the IRP is currently pending? This IRP tells us that the system has told the device to transition from its standy mode to power state, however, it appears to become stuck therefore leading to the crash which has occured.

The minor code IRP_MN_WAIT_WAKE simply sends a wake signal to the device, which in turn will produce another power IRP which will tell the driver to transistion to a fully powered state. The wake signal may originate on desktop screens may be a nofication or the movement of the mouse cursor.

The next driver is the IRP stack appears to be related to your Intel network driver:

Code: 
0: kd> [COLOR=#008000]lmvm e1d65x64[/COLOR]

start             end                 module name
fffff80b`89950000 fffff80b`899da000   e1d65x64   (no symbols)           
    Loaded symbol image file: e1d65x64.sys
    Image path: \SystemRoot\system32\DRIVERS\e1d65x64.sys
    Image name: e1d65x64.sys
    Timestamp:        [COLOR=#ff0000]Wed Jul 12 14:29:18 2017 [/COLOR](5966242E)
    CheckSum:         0008DB2A
    ImageSize:        0008A000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

This isn't to say that the driver is at fault, but it provides some indication of where the system is crashing and which device drivers may be responsible.

Just picked another power IRP from the list, and it appears that the Xbox driver which cwsink mentioned is present.

Code: 
0: kd> [COLOR=#008000]!irp ffffd40e753a1ab0[/COLOR]
Irp is active with 16 stacks 12 is current (= 0xffffd40e753a1e98)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
            0  1 ffffd40e76eeda90 00000000 00000000-00000000    [COLOR=#ff0000]pending[/COLOR]
 \Driver\USBHUB3
            Args: 00000005 00000000 00000000 00000000
 [IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
            0 e0 ffffd40e76e5b430 00000000 fffff80b8707f3e0-ffffd40e752d41a0 Success Error Cancel 
           \Driver\ACPI    ndis!ndisWaitWakeIoCompletion
            Args: 00000005 00000000 00000000 00000000
 [IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
            0 e0 ffffd40e752d4050 00000000 fffff80b88c72aa0-ffffbb8d0cab5208 Success Error Cancel 
          *** ERROR: Module load completed but symbols could not be loaded for mt7612US.sys
 \Driver\mt7612US    xboxgip!gipFilterGenericCompletionRoutine
            Args: 00000005 00000000 00000000 00000000
 [IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
            0 e0 ffffd40e76f8d6e0 00000000 fffff80087f21890-ffffd40e753a9bd0 Success Error Cancel 
           \Driver\xboxgip    nt!PopRequestCompletion
            Args: 00000005 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-ffffd40e753a9bd0    

            Args: 00000000 00000000 00000000 00000000

I would just updating the Xbox driver and ensuring that anything network related is updated too such as security programs.

Code: 
0: kd> [COLOR=#008000]lmvm mt7612US[/COLOR]
Browse full module list
start             end                 module name
fffff80b`88c00000 fffff80b`88c61000   mt7612US   (no symbols)           
    Loaded symbol image file: mt7612US.sys
    Image path: \SystemRoot\System32\drivers\mt7612US.sys
    Image name: mt7612US.sys
    Browse all global symbols  functions  data
    Timestamp:        [COLOR=#ff0000]Wed Dec 09 06:44:11 2015[/COLOR] (5667CDBB)
    CheckSum:         00062A42
    ImageSize:        00061000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

The device stack for the IRP:

Code: 
0: kd> [COLOR=#008000]!devstack ffffd40e76eeda90[/COLOR]
  !DevObj           !DrvObj            !DevExt           ObjectName
  ffffd40e76f8d6e0  \Driver\xboxgip    ffffd40e76f8d830  
  ffffd40e752d4050  \Driver\mt7612US   ffffd40e752d41a0  NDMP3
  ffffd40e76e5b430  \Driver\ACPI       ffffd40e7220ebe0  
> ffffd40e76eeda90  \Driver\USBHUB3    ffffd40e76eea600  USBPDO-9
!DevNode ffffd40e75228100 :
  DeviceInst is "USB\VID_045E&PID_02E6\470636"
  ServiceName is "[COLOR=#ff0000]mt7612US[/COLOR]"
 
Thank you for the comprehensive breakdown, Robot. You've made it very easy for me to follow. But does this mean that this dump was indeed not written in response to the freeze itself, as cwsink posited? You mentioned that this dump was written when exiting standby mode, but I was actively using the computer when the system froze.

I've also gone ahead and just updated the driver for the Xbox controller (Then unplugged it entirely for good measure), but these I doubt this is what's been causing the freezes as this issue predates my actually owning/using the adapter. Also interesting to note that when the adapter is plugged into certain USB3 ports on my motherboard, the device driver will sometimes fail to start when booting the system (Indicated by a warning from the Windows security center and an error in the device manager). I have similar difficulties when plugging the controller itself directly into those USB3 slots via cable - it'll only work a few minutes before the controller abruptly stops working (the light remains on, but it gets stuck on the last button presses). It only occurs when plugged into USB3 and doesn't seem to occur with any of my other USB devices, so I've always assumed it to be either a mildly defective USB port or just some manner of incompatibility with the board. Dunno if any of this is relevant or if it could be what's causing those errors you're seeing to appear, but I thought it worth mentioning.
 
Are there enough Intel USB ports (as opposed to the ASMedia or VIA ports) such that you can connect all your devices only to Intel ports? I've seen situations where some devices don't do power management well with anything but Intel components. I get the impression everybody makes sure their products work with Intel components but not everyone takes the time to make sure they work with the other manufacturer's components.
 
Very nice, BlueRobot. Thank you for the great case notes; very informative.
 
I have five USB devices in total. Two of them were plugged into the Intel USB2 ports (Keyboard and mouse) and the other three were evidently plugged into the VIA USB3 ports (Microphone, tablet and Xbox controller). With the controller unplugged, I've moved the other two to the Intel USB ports.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top