Gigabyte AERO 16 YE5 experiences crashes, BSODs, and screen issues accompanied by a buzzing noise.
Gigabyte AERO 16 YE5 experiences crashes, BSODs, and screen issues accompanied by a buzzing noise.
Adjust the page file location to the D: drive using this procedure (applies to Windows 10). This should help retrieve crash-related dump files. If you're already on D:, move it over to C:. If both drives are present, switch to using just one. Be sure the suspect drive appears as faulty in your diagnostics.
The guide you referenced was straightforward to understand. I'm aiming to resolve this matter quickly. I'm checking the RAM from Gigabyte once it arrives to determine if it resolves my issue right away. I'll share additional dump files from the D: drive later. Appreciate your support.
Your laptop has had a few crashes, but you're having trouble finding the minidump folder on your D: drive. It seems the usual search paths aren't yielding results. You might want to look for files labeled differently or check other locations such as the system logs or startup directories. Also, consider searching for "Page Faults" or similar error codes, as they could be relevant.
It seems the crash was recorded on the C: drive minidump, but the OSNAME indicates Windows 10. You're using Windows 11 Pro now.
The dump folder remains at the original location, C:\Windows\Minidump. The page file is now on the D: drive. You may also receive kernel dumps that are quite large—so I recommend using minidumps instead, as they work well in about 99% of cases. This guide shows how to set it up for minidumps. Kernel dumps are stored in C:\Windows, Memory.dmp. If possible, upload them but remember to compress them first to cut down the size significantly. The most recent crash involved DirectX, likely related to GPU issues, though this time it seemed to be memory-related.
Oh Okay thanks for breaking that down for me to understand. I checked for Memory.dmp in the windows folder and after some digging it looks like ""Write debugging information" in system settings was set to minidump but I've changed that now to allow for automatic memory dump which created a Memory.dmp file. I'll post one when it generates. Thanks.
You can try sharing a smaller version or using an alternative method for uploading the file.
BUGCHECK_CODE: c1 BUGCHECK_P1: ffffaa0e26bb2f80
BUGCHECK_P2: ffffaa0e26bb2600
BUGCHECK_P3: 274078
BUGCHECK_P4: 23 FILE_IN_CAB
MEMORY.DMP DUMP_FILE_ATTRIBUTES: 0x1000
SPECIAL_POOL_CORRUPTION_TYPE: 23
BLACKBOXBSD: 1 ( !blackboxbsd )
BLACKBOXNTFS: 1 ( !blackboxntfs )
BLACKBOXPNP: 1 ( !blackboxpnp )
BLACKBOXWINLOGON: 1
PROCESS_NAME: System
STACK_TEXT: ffffdd82`e922f4e8 fffff804`23c2c745
FILENAME: 00000000`000000c1 ffffaa0e`26bb2f80 ffffaa0e`26bb2600
ATTACHMENTS: 0x1000 SPECIAL_POOL_CORRUPTION_TYPE=23
BLACKBOXINFO:
- BLACKBOXBSD: enabled
- BLACKBOXNTFS: enabled
- BLACKBOXPNP: enabled
- BLACKBOXWINLOGON: enabled
- EXPANSE: 0
- HEAP SPECIAL POOL CORRUPTION: type 23
PROCESS DETAILS:
- BUG CHECKED: nt!KeBugCheckEx
- TAG: ffffaa0e`26bb2f80
- HEAP STATE: 00000000`00000000
- FILE SIZE: 00274078 bytes
- NO ADDITIONAL CONTEXT AVAILABLE
No new findings that clearly indicate anything. Both of the recent updates include DirectX, suggesting a GPU involvement, but this doesn’t clarify why the initial set of dump files appears unrelated to GPU. The crashes occur during memory interactions. The most recent issue seems to be related to VRAM rather than RAM. Also, the reason shown in the dump files is that Windows 10, while Windows 11 is essentially built on top of it.
Recent log from ten minutes prior shows DMP details. Memory address 0x1000 is being read. Process name matches svchost.exe. A trap frame was triggered, but not all registers are present—some values appear zeroed or incorrect. Specific registers: rax=ffffc008c056faa0, rbx=00000000, etc. Additional info includes rsp, rbp, r8, r9, r10, r11, r12, r13, r14, r15, iopl, and a note about missing data.