|
Внезапные зависания системы Windows 10 во время работы
Вложений: 2
В течение месяца, вне зависимости от моих действий, намертво зависает ноутбук на 30-60 секунд, изредка на несколько минут: все действия зависают, кроме переключения окон, вкладок и т.д.
Большинство зависаний зафиксировать не получалось, после отвисания в диспетчере задач нельзя было найти какой-либо виновный за эти зависания процесс. Во время особенно длинных зависаний по (3-5 минут) в журнале событий было записано несколько предупреждений от ESENT с кодами 508 и 533:  Скрытый текст
6/29/2020 16:31:10
qmgr.dll (5592,T,97) QmgrDatabaseInstance: A request to write to the file "C:\ProgramData\Microsoft\Network\Downloader\qmgr.db" at offset 16384 (0x0000000000004000) for 16384 (0x00004000) bytes succeeded, but took an abnormally long time (36 seconds) to be serviced by the OS. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. 6/29/2020 16:30:24 qmgr.dll (5592,T,0) QmgrDatabaseInstance: A request to write to the file "C:\ProgramData\Microsoft\Network\Downloader\qmgr.db" at offset 16384 (0x0000000000004000) for 16384 (0x00004000) bytes has not completed for 36 second(s). This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. 6/27/2020 15:48:16 svchost (4328,D,0) SRUJet: A request to write to the file "C:\WINDOWS\system32\SRU\SRU.log" at offset 16384 (0x0000000000004000) for 4096 (0x00001000) bytes succeeded, but took an abnormally long time (30 seconds) to be serviced by the OS. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. 6/27/2020 15:44:51 svchost (15148,D,0) Unistore: A request to write to the file "C:\Users\F-Mir\AppData\Local\Comms\UnistoreDB\store.vol" at offset 13074432 (0x0000000000c78000) for 12288 (0x00003000) bytes succeeded, but took an abnormally long time (113 seconds) to be serviced by the OS. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. 6/27/2020 15:43:38 svchost (15148,D,0) Unistore: A request to write to the file "C:\Users\F-Mir\AppData\Local\Comms\UnistoreDB\store.vol" at offset 13074432 (0x0000000000c78000) for 12288 (0x00003000) bytes has not completed for 36 second(s). This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. 6/14/2020 14:49:01 SettingSyncHost (18948,T,97) {2712A304-7D0F-47A5-A4E5-14AAB3358EBD}: A request to write to the file "C:\Users\F-Mir\AppData\Local\Microsoft\Windows\SettingSync\metastore\meta.edb" at offset 0 (0x0000000000000000) for 16384 (0x00004000) bytes succeeded, but took an abnormally long time (17 seconds) to be serviced by the OS. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. Сегодня через монитор ресурсов пытался выяснить, кто использует диск до такой степени, что система виснет. Но в момент зависания все показания обнулились… (см прикрепления) |
Miralius, СМАРТ ж/д смотрели, в норме?
Ф/с на томах ж/д на ошибки проверяли? |
Да, со SMARTом, кажется, все хорошо. Проблемы возникают на системном диске, т.е. на SSD.
 Проверял дважды позавчера chkdsk системный диск. Находил одну ошибку. chkdsk
Checking file system on C:
The type of the file system is NTFS. Volume label is System. The volume is dirty. Stage 1: Examining basic file system structure ... File 0x7410 has bad reparse point attribute. ReparseDataLength, 0x1000, inconsistence with the attribute length 0x171. Deleting corrupt attribute record (0xC0, "") from file record segment 0x7410. Cleaning up instance tags for file 0x36a21. Cleaning up instance tags for file 0x36ab2. Cleaning up instance tags for file 0x36c5a. Cleaning up instance tags for file 0x36c78. Cleaning up instance tags for file 0x36c88. 1550336 file records processed. File verification completed. Phase duration (File record verification): 17.04 seconds. 8496 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 1.40 milliseconds. Stage 2: Examining file name linkage ... The reparse flag in standard information attribute in file 0x7410 should not be set. Correcting reparse point file record segment 7410. The reparse point index entry in file 0x1a points to file 0x7410 but the file has no reparse point in it. Deleting an index entry from index $R of file 1A. 26116 reparse records processed. The file reference 0x66000000016c25 of index entry {2ACD1~1 of index $I30 with parent 0x17e36 is not the same as 0x77000000016c25. Deleting index entry {2ACD1~1 in index $I30 of file 17E36. The file reference 0x3b00000001ba30 of index entry {46A83~1 of index $I30 with parent 0x17e36 is not the same as 0x7000000001ba30. Deleting index entry {46A83~1 in index $I30 of file 17E36. 1819588 index entries processed. Index verification completed. Phase duration (Index verification): 44.53 seconds. CHKDSK is scanning unindexed files for reconnect to their original directory. 1 unindexed files scanned. 0 unindexed files recovered to original directory. Phase duration (Orphan reconnection): 0.00 milliseconds. CHKDSK is recovering remaining unindexed files. 1 unindexed files recovered to lost and found. Lost and found is located at \found.000 Phase duration (Orphan recovery to lost and found): 0.00 milliseconds. 26116 reparse records processed. Phase duration (Reparse point and Object ID verification): 60.60 milliseconds. Stage 3: Examining security descriptors ... Cleaning up 4525 unused index entries from index $SII of file 0x9. Cleaning up 4525 unused index entries from index $SDH of file 0x9. Cleaning up 4525 unused security descriptors. Security descriptor verification completed. Phase duration (Security descriptor verification): 63.81 milliseconds. 134627 data files processed. Phase duration (Data attribute verification): 1.66 milliseconds. CHKDSK is verifying Usn Journal... Usn Journal verification completed. Correcting errors in the master file table's (MFT) BITMAP attribute. Windows has made corrections to the file system. No further action is required. 249283580 KB total disk space. 152643100 KB in 821662 files. 415872 KB in 134629 indexes. 0 KB in bad sectors. 1629796 KB in use by the system. 65536 KB occupied by the log file. 94594812 KB available on disk. 4096 bytes in each allocation unit. 62320895 total allocation units on disk. 23648703 allocation units available on disk. Total duration: 1.11 minutes (67158 ms). chkdsk c: /f /r
Checking file system on C:
The type of the file system is NTFS. Volume label is System. A disk check has been scheduled. Windows will now check the disk. Stage 1: Examining basic file system structure ... 1550336 file records processed. File verification completed. Phase duration (File record verification): 14.48 seconds. 8493 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 1.39 milliseconds. Stage 2: Examining file name linkage ... 26116 reparse records processed. 1819586 index entries processed. Index verification completed. Phase duration (Index verification): 57.00 seconds. 0 unindexed files scanned. Phase duration (Orphan reconnection): 2.52 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 6.57 milliseconds. 26116 reparse records processed. Phase duration (Reparse point and Object ID verification): 44.91 milliseconds. Stage 3: Examining security descriptors ... Cleaning up 22 unused index entries from index $SII of file 0x9. Cleaning up 22 unused index entries from index $SDH of file 0x9. Cleaning up 22 unused security descriptors. Security descriptor verification completed. Phase duration (Security descriptor verification): 44.62 milliseconds. 134626 data files processed. Phase duration (Data attribute verification): 1.55 milliseconds. CHKDSK is verifying Usn Journal... 2670768 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 29.36 milliseconds. Stage 4: Looking for bad clusters in user file data ... 1550320 files processed. File data verification completed. Phase duration (User file recovery): 26.35 minutes. Stage 5: Looking for bad, free clusters ... 23584160 free clusters processed. Free space verification is complete. Phase duration (Free space recovery): 0.00 milliseconds. Windows has scanned the file system and found no problems. No further action is required. 249283580 KB total disk space. 152898156 KB in 818986 files. 415904 KB in 134627 indexes. 0 KB in bad sectors. 1632880 KB in use by the system. 65536 KB occupied by the log file. 94336640 KB available on disk. 4096 bytes in each allocation unit. 62320895 total allocation units on disk. 23584160 allocation units available on disk. Total duration: 27.59 minutes (1655753 ms). UPD: Сейчас снова запустил проверку диска через ПКМ по диску → свойства → инструменты → Проверить диск. Сразу после запуска проверки ноутбук снова завис на 2 минуты. Во время зависания прогресс проверки стоял на месте. После отвисания проверка пошла, была большая активность от dllhost. В журнале событий записалось: Windows Error reporting 1001
Fault bucket 1409744833567330181, type 5
Event Name: RADAR_PRE_LEAK_64 Response: Not available Cab Id: 0 Problem signature: P1: dllhost.exe P2: 10.0.19041.1 P3: 10.0.19041.2.0.0 P4: P5: P6: P7: P8: P9: P10: Attached files: \\?\C:\Users\F-Mir\AppData\Local\Temp\RDRE1B3.tmp\empty.txt \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERE1B4.tmp.WERInternalMetadata.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERE1D4.tmp.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERE1CF.tmp.csv \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERE20F.tmp.txt These files may be available here: Analysis symbol: Rechecking for solution: 0 Report Id: dbd49ab4-45f0-46ea-8323-7dea9cac37cc Report Status: 268435456 Hashed bucket: 0d81c094a7fe188bc3906b74fcb90f85 Cab Guid: 0 |
а что вообще с температурой по датчикам у вас? На мостах?
А то 62 у хдд, не очень хорошо |
 Вот температуры через AIDA64. 62 градуса было у NVMe SSD, у HDD 38 градусов. |
Цитата:
СМАРТ второго также покажите пжлст. |
SMART второго диска (HDD):
 |
Miralius, здесь все чинно-красиво, спс.
|
NickM, а мне что делать?:) Есть какие-либо версии программных багов? Сам я думаю на SSD, и пока ноутбук на гарантии, хотелось бы его в случае брака заменить по гарантии.
|
Miralius, пробуйте пару-тройку дней проверять ф/с на загрузочном томе, если будет биться, тогда грешите на твердотельник, ведь на ровном месте ошибки не появляются (к слову, твердотельник так Себе, при 12WTB уже почти 20% износа :( ).
Если не затруднит, приложите системные журналы, может там, что можно будет увидеть. |
Экспортировал журналы System и Application, надеюсь, я сделал это правильно. Сюда прикрепить места не хватает, выложил на диск.
|
Miralius, ну, ошибки в журналах конечно присутствуют, тут и внезапные выключения, и ошибки запуска служб, и повторяющиеся ошибки DCOM (возможно не так страшно), и ошибки диска, правда прошлого месяца:
Цитата:
Не думали ли переустановить систему в режиме обновления? Может часть ошибок бы ушла автоматически, а оставшиеся можно было бы локализовать? А firmware BIOS какой у Вас версии? На сайте так-то от 17-го числа объявилась... |
NickM, переустановку можно попробовать, как раз свободное время объявилось.
Как раз позавчера ставил эту новую версию UEFI, в надежде, что это избавит меня от этой ошибки:) Но не помогло. |
Была такая проблема. Причём не только на вин10, но и на вин7. Появилась после замены ссд м2 сата на новый нвме. Копайте в ту сторону. На саташном ссд, такой баги не было.
|
azbuk, система с самого начала расположена на NVMe SSD, который шел вместе с ноутбуком. Другое дело, что раньше этой баги не было, она появилась в этом месяце. Можно ещё подумать, что это из-за обновления Windows 10 2004, ибо это обновление вышло в конце мая.
|
Я как раз на новый нвмешный диск 2 системы накатывал. Вин7sp1 и вин10-1809 (дуалбут), тогда и появилось зависание. После подачи TRIM (в вин10, раз уж нвме) зависания исчезли.
|
azbuk, TRIM, кажется, я уже несколько раз делал, с помощью стандартной утилиты дефрагментации. Кстати, что может быть интересным, она постоянно требует для SSD выполнить оптимизацию. Буквально сделал retrim, через 5 минут снова пишет, что нужна оптимизация диска.
Ещё я забыл упомянуть, что полмесяца назад, 16 июня, был BSOD с ошибкой WHEA UNCORRECTABLE ERROR. Дамп не был создан, хотя такая возможность в свойствах системы включена: Цитата:
|
Переустановил систему, полностью переразметив SSDшник. На чистой системе всё равно наблюдались эти зависания:(
|
Цитата:
|
sondz7, я через diskpart выбрал ssd и ввел команду clean. Не вижу в ней ничего страшного, кроме того, что она удаляет таблицы GPT, и я установщиком Windows создал разделы заново.
|
Цитата:
 а теперь считайте сколько переустановок останется до его конца с вашими манипуляциями. |
sondz7, честно говоря, не понимаю, как может перезапись нескольких мегабайт (таблицы NTFS, GPT) убивать диск:) Обычная работа системы и программ больше перезаписей выполняет, нежели переразметка диска (без полного форматирования, конечно же!).
|
Цитата:
|
sondz7, спасибо, это уже интересно. Ноутбук был куплен в декабре, за почти полгода намотало 12ТБ записи. Это аж 60-70Гб в день О_о. Наверно, это весьма большая цифра.
Насчёт установок и переразметок. Я как купил ноутбук, поставил на него систему, так до сегодняшнего дня не переустанавливал. Сегодня была первая переустановка с прошлого года. Чем я мог так много записывать на SSD, я не представляю. Разве только тем, что я программирую на нем почти каждый день, папки с проектами быстро набирают вес до 10-15 гб:) Наверно, там весьма интенсивная запись идёт. P.S.: Я перенес сейчас систему на HDD. Посмотрю, как будет работать на нём. UPD: А вообще, простые расчёты на калькуляторе дают следующее: 70Гб в день → ноутбук работает круглосуточно → ≈850 Кб/с. Сейчас через монитор ресурсов наблюдаю фоновую активность браузера (он тоже постоянно включен) на уровне 300-400 Кб/с, чтения и записи поровну. Вот так и набрало, наверно, 12Тб:) |
Цитата:
Скажу больше, мой личный первый SSD - простенький 30Гб kingmax куплен в 2008г. года три активно отработал с winXP, которая в принципе не знала что такое ssd и регулярно дефрагментировала данные. +несчётное количество установок/переустановок/переразметок прочих экспериментов с win. Так вот он до сих пор отлично работает и даже скорость чтения/записи показывает выше заявленной)) и да, smart ssd почти никогда ни о чём не говорит. это не древние харды, SSD либо работает либо сразу отваливается. |
| Время: 20:09. |
Время: 20:09.
© OSzone.net 2001-