Множество синих экранов с разными кодами ошибки

Question

Практически каждый день вылетают синие экраны с разными кодами ошибок. BlueScreenView говорит, что дело в ntoskrnl.exe. Пробовал переустанавлить виндовс, пробовал переустанавливать драйвера, тестировал оперативную память и встроенными инструментами Windows и при помощи memtest86+, проверял жёсткие диски на повреждённые секторы. Ничего не помогает.
Специально накопил 5 дамп-файлов. Вот ссылка: drive.google.com/drive/folders/1xU9ItSiaXOEq38khy37Nzz9fsUg5T3_v?usp=sharing
Пожалуйста, помогите 😭

Answer 1

Добрый день, извините за задержку. Полностью переустанавливал виндовс с полным форматированием жёстких дисков. Скачивал только лицензионые версии программ, но всё равно вылетает синий экран. Вот фотографии, которые вы просили:

Проблема в том, что на ПК установлена пиратская ОС, активированная нелегально краденым корпоративным ключом MAK. Вам следует приобрести лицензию и выполнить чистую установку ОС с активацией подлинным ключом из комплекта покупки.

Answer 2

Добрый день, извините за задержку. Полностью переустанавливал виндовс с полным форматированием жёстких дисков. Скачивал только лицензионые версии программ, но всё равно вылетает синий экран. Вот фотографии, которые вы просили:

Answer 3

[102024-8000-01.dmp]

APC_INDEX_MISMATCH (1)

This is a kernel internal error. The most common reason to see this

BugCheck is when a filesystem or a driver has a mismatched number of

calls to disable and re-enable APCs. The key data item is the

Thread->CombinedApcDisable field. This consists of two separate 16-bit

fields, the SpecialApcDisable and the KernelApcDisable. A negative value

of either indicates that a driver has disabled special or normal APCs

(respectively) without re-enabling them; a positive value indicates that

a driver has enabled special or normal APCs (respectively) too many times.

Arguments:

Arg1: 00007fff1e2f0e84, Address of system call function or worker routine

Arg2: 0000000000000000, Thread->ApcStateIndex

Arg3: 0000000000010000, (Thread->SpecialApcDisable << 16) | Thread->KernelApcDisable

Arg4: ffff8201fcc14b80, Call type (0 - system call, 1 - worker routine)

PROCESS_NAME: chrome.exe

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

IMAGE_VERSION: 10.0.19041.5007

FAILURE_BUCKET_ID: 0x1_SysCallNum_1cd_nt!KiSystemServiceExitPico

[101724-6562-01.dmp]

KERNEL_AUTO_BOOST_LOCK_ACQUISITION_WITH_RAISED_IRQL (192)

A lock tracked by AutoBoost was acquired while executing at DISPATCH_LEVEL or

above.

Arguments:

Arg1: ffffcb86c5c6d080, The address of the thread.

Arg2: ffffa1c40a1293b0, The lock address.

Arg3: 0000000000000000, The IRQL at which the lock was acquired.

Arg4: 0000000000000000, Reserved.

PROCESS_NAME: explorer.exe

MODULE_NAME: win32kbase

IMAGE_NAME: win32kbase.sys

FAILURE_BUCKET_ID: 0x192_win32kbase!HANDLELOCK::vLockHandle

[101524-6953-01.dmp]

INVALID_WORK_QUEUE_ITEM (96)

This message occurs when KeRemoveQueue removes a queue entry whose flink

or blink field is null. This is almost always called by code misusing

worker thread work items, but any queue misuse can cause this. The rule

is that an entry on a queue may only be inserted on the list once. When an

item is removed from a queue, it's flink field is set to NULL. This BugCheck

occurs when remove queue attempts to remove an entry, but the flink or blink

field is NULL. In order to debug this problem, you need to know the queue being

referenced.

In an attempt to help identify the guilty driver, this BugCheck assumes the

queue is a worker queue (ExWorkerQueue) and prints the worker routine as

parameter 4 below.

Arguments:

Arg1: ffff8b8c4f5533e0, The address of the queue entry whose flink/blink field is NULL

Arg2: ffff8b8c4f4e27c0, The address of the queue being references. Usually this is one

of the ExWorkerQueues.

Arg3: ffff8b8c3d49db00, The base address of the ExWorkerQueue array. This will help determine

if the queue in question is an ExWorkerQueue and if so, the offset from

this parameter will isolate the queue.

Arg4: 0000000000000502, If this is an ExWorkerQueue (which it usually is), this is the address

of the worker routine that would have been called if the work item was

valid. This can be used to isolate the driver that is misusing the work

queue.

PROCESS_NAME: Discord.exe

MODULE_NAME: win32kfull

IMAGE_NAME: win32kfull.sys

FAILURE_BUCKET_ID: 0x96_win32kfull!xxxRealSleepThread

[101524-6843-01.dmp]

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: 0000000000000000, memory referenced

Arg2: 00000000000000ff, IRQL

Arg3: 0000000000000000, value 0 = read operation, 1 = write operation

Arg4: 0000000000000000, address which referenced memory

PROCESS_NAME: System

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

FAILURE_BUCKET_ID: DISABLED_INTERRUPT_FAULT_CODE_AV_NULL_IP_nt!KiPageFault

[101424-6953-01.dmp]

PAGE_FAULT_IN_NONPAGED_AREA (50)

Invalid system memory was referenced. This cannot be protected by try-except.

Typically the address is just plain bad or it is pointing at freed memory.

Arguments:

Arg1: ffffb98a99f915e0, memory referenced.

Arg2: 0000000000000000, X64: bit 0 set if the fault was due to a not-present PTE.

bit 1 is set if the fault was due to a write, clear if a read.

bit 3 is set if the processor decided the fault was due to a corrupted PTE.

bit 4 is set if the fault was due to attempted execute of a no-execute PTE.

- ARM64: bit 1 is set if the fault was due to a write, clear if a read.

bit 3 is set if the fault was due to attempted execute of a no-execute PTE.

Arg3: fffff806532039de, If non-zero, the instruction address which referenced the bad memory

address.

Arg4: 0000000000000002, (reserved)

PROCESS_NAME: System

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

FAILURE_BUCKET_ID: AV_R_(null)_nt!ExAcquireRundownProtectionCacheAwareEx

..................................................

Ошибки в работе ядра ОС. Могут быть вызваны видоизменением ядра, либо вмешательством стороннего или вирусного ПО.
Выложите здесь скриншоты:

1. Окна Панель управления-Программы и компоненты со списком всех установленных программ.
2. Окна команды slmgr.vbs /dlv

Answer 4

Здравствуйте.

Дампы загрузил. Анализ займет какое то время. Как будут результаты-напишу.