dwm.exe causing BSOD "DRIVER_OVERRAN_STACK_BUFFER" in W10

I have a high frequency of BSODs in my computer pointing to many different reasons. A recent case is this dwm.exe causing "DRIVER_OVERRAN_STACK_BUFFER" BSOD. How can I fix it? Btw I'm under the impression I'm getting this BSOD while playing CS GO. My computer:

• AMD Ryzen 7 1800x + NVIDIA GeForce GTX 1060 6GB MSI, 8GB RAM Corsair LPX Vengeance (1 part missing)

As someone who experiences dozens of BSOD per month, I've already checked memory, updated drivers, reinstalled Windows (keeping the drivers), did those scanf chkdsk etc.. Here is memory.dmp analyze results:

Microsoft (R) Windows Debugger Version 10.0.18362.1 AMD64 Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP] Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.

Symbol search path is: srv* Executable search path is: Windows 10 Kernel Version 18362 MP (16 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 18362.1.amd64fre.19h1_release.190318-1202 Machine Name: Kernel base = 0xfffff8031ae00000 PsLoadedModuleList = 0xfffff8031b248150 Debug session time: Fri Apr 3 19:02:33.498 2020 (UTC - 3:00) System Uptime: 1 days 1:41:00.176 Loading Kernel Symbols ............................................................... ................................................................ ................................................................ .. Loading User Symbols PEB is paged out (Peb.Ldr = 00000088`f09c8018). Type ".hh dbgerr001" for details Loading unloaded module list .......... For analysis of this file, run !analyze -v 4: kd> !analyze -v

---

• *
• Bugcheck Analysis *
• *

  ---

DRIVER_OVERRAN_STACK_BUFFER (f7) A driver has overrun a stack-based buffer. This overrun could potentially allow a malicious user to gain control of this machine. DESCRIPTION A driver overran a stack-based buffer (or local variable) in a way that would have overwritten the function's return address and jumped back to an arbitrary address when the function returned. This is the classic "buffer overrun" hacking attack and the system has been brought down to prevent a malicious user from gaining complete control of it. Do a kb to get a stack backtrace -- the last routine on the stack before the buffer overrun handlers and bugcheck call is the one that overran its local variable(s). Arguments: Arg1: ffffe70ae08b5888, Actual security check cookie from the stack Arg2: 0000fc951f5cc688, Expected security check cookie Arg3: ffff036ae0a33977, Complement of the expected security check cookie Arg4: 0000000000000000, zero

Debugging Details:

KEY_VALUES_STRING: 1

PROCESSES_ANALYSIS: 1

SERVICE_ANALYSIS: 1

STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1

DUMP_CLASS: 1

DUMP_QUALIFIER: 401

BUILD_VERSION_STRING: 18362.1.amd64fre.19h1_release.190318-1202

SYSTEM_MANUFACTURER: System manufacturer

SYSTEM_PRODUCT_NAME: System Product Name

SYSTEM_SKU: SKU

SYSTEM_VERSION: System Version

BIOS_VENDOR: American Megatrends Inc.

BIOS_VERSION: 5220

BIOS_DATE: 09/12/2019

BASEBOARD_MANUFACTURER: ASUSTeK COMPUTER INC.

BASEBOARD_PRODUCT: PRIME X370-PRO

BASEBOARD_VERSION: Rev X.0x

DUMP_TYPE: 1

BUGCHECK_P1: ffffe70ae08b5888

BUGCHECK_P2: fc951f5cc688

BUGCHECK_P3: ffff036ae0a33977

BUGCHECK_P4: 0

SECURITY_COOKIE: Expected 0000fc951f5cc688 found ffffe70ae08b5888

CPU_COUNT: 10

CPU_MHZ: e09

CPU_VENDOR: AuthenticAMD

CPU_FAMILY: 17

CPU_MODEL: 1

CPU_STEPPING: 1

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)

BLACKBOXWINLOGON: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xF7

PROCESS_NAME: dwm.exe

CURRENT_IRQL: 0

ANALYSIS_SESSION_HOST: doesn't matter ;)

ANALYSIS_SESSION_TIME: 04-03-2020 19:08:42.0261

ANALYSIS_VERSION: 10.0.18362.1 amd64fre

LOCK_ADDRESS: fffff8031b262940 -- (!locks fffff8031b262940)

Resource @ nt!PiEngineLock (0xfffff8031b262940) Available Contention Count = 50 1 total locks

PNP_TRIAGE_DATA: Lock address : 0xfffff8031b262940 Thread Count : 0 Thread address: 0x0000000000000000 Thread wait : 0x0

LAST_CONTROL_TRANSFER: from fffff8031b07c8a5 to fffff8031afc2380

STACK_TEXT: ffffe70ae08b4638 fffff8031b07c8a5 : 00000000000000f7 ffffe70ae08b5888 0000fc951f5cc688 ffff036ae0a33977 : nt!KeBugCheckEx ffffe70ae08b4640 fffff8031afa2c82 : ffffe70ae08b4780 0000021c00000393 ffff862f61dc86b0 0000000000000000 : nt!_report_gsfailure+0x25 ffffe70ae08b4680 fffff8031afa2c17 : 0000000000000004 fffff8031aefe23e ffffe70ae08b4900 ffffe70ae08b47c0 : nt!_GSHandlerCheckCommon+0x5a ffffe70ae08b46b0 fffff8031afcb1b2 : fffff8031b311000 fffff8031ae00000 0005e38c00ab7000 000000000010001f : nt!_GSHandlerCheck+0x13 ffffe70ae08b46e0 fffff8031aefa2d5 : ffffe70ae08b5648 0000000000000000 ffffe70ae08b4c50 00007fffffff0000 : nt!RtlpExecuteHandlerForException+0x12 ffffe70ae08b4710 fffff8031aefe86e : ffffe70ae08b5648 ffffe70ae08b5390 ffffe70ae08b5648 0000000000000018 : nt!RtlDispatchException+0x4a5 ffffe70ae08b4e60 fffff8031afd431d : 0000000000000000 0000000000000003 0000000000000000 0000000000000000 : nt!KiDispatchException+0x16e ffffe70ae08b5510 fffff8031afce8ab : 0000000000000000 ffff988700000000 ffff988700000000 0000000000000000 : nt!KiExceptionDispatch+0x11d ffffe70ae08b56f0 fffff8031b500010 : fffff8031b47fdc2 0000000040003002 ffffe70ae08b59c0 ffff98875381d8c0 : nt!KiInvalidOpcodeFault+0x32b ffffe70ae08b5888 ffff9887513c74c0 : 0000000000000001 ffff98873d0e40c0 ffffe70ae08b5901 0000000000000000 : nt!PipChangeDeviceObjectFromRegistryProperties+0x6c ffffe70ae08b5988 0000000000000001 : ffff98873d0e40c0 ffffe70ae08b5901 0000000000000000 0000000000000001 : 0xffff9887513c74c0 ffffe70ae08b5990 ffff98873d0e40c0 : ffffe70ae08b5901 0000000000000000 0000000000000001 00000088f0cff950 : 0x1 ffffe70ae08b5998 ffffe70ae08b5901 : 0000000000000000 0000000000000001 00000088f0cff950 0000000000000000 : 0xffff98873d0e40c0 ffffe70ae08b59a0 0000000000000000 : 0000000000000001 00000088f0cff950 0000000000000000 ffff988749b1e9f0 : 0xffffe70a`e08b5901

THREAD_SHA1_HASH_MOD_FUNC: 5623a1b98475ed6ab422ac153734b81ff4cf1dbe

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 7ad2c9f635f506810a75d2f7d9c01177b7a094a4

THREAD_SHA1_HASH_MOD: bc100a5647b828107ac4e18055e00abcbe1ec406

FOLLOWUP_IP: nt!_report_gsfailure+25 fffff803`1b07c8a5 cc
int 3

FAULT_INSTR_CODE: cccccccc

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!_report_gsfailure+25

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: 25

FAILURE_BUCKET_ID: 0xF7_MISSING_GSFRAME_nt!_report_gsfailure

BUCKET_ID: 0xF7_MISSING_GSFRAME_nt!_report_gsfailure

PRIMARY_PROBLEM_CLASS: 0xF7_MISSING_GSFRAME_nt!_report_gsfailure

TARGET_TIME: 2020-04-03T22:02:33.000Z

OSBUILD: 18362

OSSERVICEPACK: 0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 272

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: unknown_date

BUILDDATESTAMP_STR: 190318-1202

BUILDLAB_STR: 19h1_release

BUILDOSVER_STR: 10.0.18362.1.amd64fre.19h1_release.190318-1202

ANALYSIS_SESSION_ELAPSED_TIME: 2690

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xf7_missing_gsframe_nt!_report_gsfailure

FAILURE_ID_HASH: {82d2c1b5-b0cb-60a5-9a5d-78c8c4284f84}

Followup: MachineOwner

Know someone who can answer? Share a link to this question via email, Twitter, or Facebook.