Chkdsk is compacting the security descriptor stream что это
Перейти к содержимому

Chkdsk is compacting the security descriptor stream что это

  • автор:

Chkdsk is compacting the security descriptor stream что это

Сообщения: 53187
Благодарности: 15437

Конфигурация компьютера
Процессор: AMD Ryzen 7 7800X3D
Материнская плата: Gigabyte B650E Aorus Master
Память: Kingston Fury Renegade DDR5-6000 32GB (2×16)
HDD: Samsung SSD 850 PRO 256GB, 980 PRO 1TB
Видеокарта: Gainward GeForce RTX 3080 追风
Блок питания: be quiet! Straight Power 11 650W
Монитор: ASUS VG248QE 24″
ОС: Windows 10 Pro x64
Прочее: корпус Fractal Design Define R4

Цитата SibUrsus:

с ОС что-то не так

Может быть что-то не так с «железом».
Потестируйте память с помощью Memtest86.
Оставляйте по одной планке (по очереди). По возможности замените.
Сбросьте настройки BIOS на default (по умолчанию). Обновите BIOS на сайте производителя материнской платы.

Сообщения: 190
Благодарности: 10

Цитата Avatar-Lion:

Посмотрите хотя бы S.M.A.R.T. жёсткого диска для начала, дайте компу повисеть пару часиков на тесте оперативки. А то очень уж похоже на аппаратные проблемы. »

Состояние жестких дисков мониторится с помощью Crystal Disk Info. Насколько ему можно верить? Файл в прицепе.

Цитата Avatar-Lion:

Если есть Dr.Web, то удалите его. Не отключайте, а именно удаляйте. »

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

Цитата Petya V4sechkin:

Сбросьте настройки BIOS на default (по умолчанию). Обновите BIOS на сайте производителя материнской платы. »

Сделано, еще год назад.

Потестируйте память с помощью Memtest86.

Память проверял, неоднократно, с помощью встроенного Средства, ошибок не обнаружено. Но обязательно сделаю по вашему совету, Live-CD есть.
Но что-то сомневаюсь.

Последний раз редактировалось SibUrsus, 21-07-2020 в 08:12 .

Сообщения: 190
Благодарности: 10

1. Оказывается в 2014 г. вышла еще версия БИОС. Обновил.
2. Все планки протестировались memtest86+ ver 4.20 порознь и со cменой слотов. Ошибок не обнаружено.

Сообщения: 5044
Благодарности: 997

Конфигурация компьютера
Процессор: Intel Core i7-970 (3,2Ghz) + Corsair Hydro H50 (СВО)
Материнская плата: ASUS Rampage III Extreme (BIOS version: 1601)
Память: Corsair CMT6GX3M3A1866C9 (6 x 2Gb)
HDD: OCZ RevoDrive 3 (240Gb)
Видеокарта: NVIDIA GeForce GTX 1050 Ti
Звук: Realtek High Definition Audio (ALC889)
Блок питания: Corsair CMPSU-850HX (850Вт), ~2009 г.
CD/DVD: LG GH22NS50
Монитор: ASUS VK278Q (27″)
Ноутбук/нетбук: ASUS EEE PC Lamborghini VX6S: Atom D2700 (2,1Ghz) | 4Gb RAM | Radeon HD 6470M (1366×768; 12,1″) | Corsair «Force 3» SSD (90Gb)
ОС: Windows 7 «Ultimate» (64-bit)
Прочее: Клавиатура: Logitech G19 | Мышь: ASUS GX850 | Акустика: SVEN-Audio HA-385

chkdsk C: /f /r сделайте и выложите отчёт.

P.S. В Безопасном режиме тоже не работает?

Сообщения: 190
Благодарности: 10

Цитата Avatar-Lion:

chkdsk C: /f /r сделайте и выложите отчёт. »

TimeCreated : 01.04.2014 17:31:00
Message :

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.

CHKDSK is verifying files (stage 1 of 5).
140032 file records processed.
File verification completed.
650 large file records processed.
0 bad file records processed.
2 EA records processed.
80 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 5).
177740 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered.
CHKDSK is verifying security descriptors (stage 3 of 5).
140032 file SDs/SIDs processed.
Cleaning up 1494 unused index entries from index $SII of file 0x9.
Cleaning up 1494 unused index entries from index $SDH of file 0x9.
Cleaning up 1494 unused security descriptors.
CHKDSK is compacting the security descriptor stream
18855 data files processed.
CHKDSK is verifying Usn Journal.
36571048 USN bytes processed.
Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5).
140016 files processed.
File data verification completed.
CHKDSK is verifying free space (stage 5 of 5).
14084407 free clusters processed.
Free space verification is complete.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

116868095 KB total disk space.
60211352 KB in 105818 files.
72924 KB in 18858 indexes.
0 KB in bad sectors.
246191 KB in use by the system.
65536 KB occupied by the log file.
56337628 KB available on disk.

4096 bytes in each allocation unit.
29217023 total allocation units on disk.
14084407 allocation units available on disk.

Internal Info:
00 23 02 00 0d e7 01 00 ef 72 03 00 00 00 00 00 .#. r.
54 02 00 00 50 00 00 00 00 00 00 00 00 00 00 00 T. P.
c0 8d 3c 00 50 01 3b 00 c0 1a 3b 00 00 00 3b 00 ..

Windows has finished checking your disk.
Please wait while your computer restarts.

Цитата Avatar-Lion:

P.S. В Безопасном режиме тоже не работает? »

Да, не работает. 2 программы, которые мне кровь сворачивают, «Налогоплательщик ЮЛ» и АРМ «Подготовка СПД» от Росфинмониторинга. В остальном вроде всё работает.

chkdsk stuck in compacting security descriptor stream

My daughter has a Compaq Presario running Vista, purchased May 2008 for college.
Last week, system advised she needed file system check. Ran through stage 1,2 no problem.
Stage 3; CHKDSK is verifying security descriptors (stage 3 of 3). Stuck at this stage for 8 hours:
CHKDSK is compacting the security descriptor stream.

Should I try again, ask for tech support, take it to a repair shop or buy a new computer?
THANX
CATTRICK
I am using Acer Aspire 1, D250, to send this and try to solve issue.

52785 posts · Joined 2003

The hard drive may be bad. If not, the file system is too damaged to repair and it needs to be replaced. Either way, you have a problem.

How are you running it? Are you running it while Windows is running (because it can’t fix things then)?

Microsoft MVP
異驚の界世 ¡pןɹoʍ ǝɥʇ ɟo sɹǝpuoʍ ǝɥʇ ɟo ǝuo sı ǝpoɔıun ʞuıɥʇ ı
cattrick Discussion starter
3 posts · Joined 2011

E
The scandisk began when she started up the computer. I’ve tried it and it always ‘recommends’ you run disk check. Works thru 2 stages everytime and always gets stuck on stage 3 «chkdsk is compact the security descriptor stream.’
Should I try to start and bypass scan disk?
She has avg pctuneup 2011 that will defrag files, repair disks, etc. I AM sure she forgot to run pc tuneup for the past 5 months.
thankx
cattrick

52785 posts · Joined 2003

Hopefully, PC Tuneup, if it is a program, will never be run. It contains a registry cleaner that will damage the system. No tools are needed for the system except what came with it. If the program made backups, restore them and get rid of it.

Do you have an Vista DVD to boot from? If you do, get a command prompt and run:

If not, and you can still get into the system, go to Start > Run, and type:

Agree to running on reboot by answering «Y» in the box that pops up and restart. Chkdsk /r will take quite a while since it does a much more complete test and repair of the file system. If you happen to see the end result, note whether any bad clusters were found.

(You should be able to press any key to skip chkdsk on startup.)

If chkdsk /r does not complete, save all the files that you need. It will be time to test the drive and replace the current partitions and file system, as well as Windows.

Eileen’s Lounge

I ran two scan disks, one on 7.9.17 and one on 7.14.17. What alarms me is that 28 KB in bad sectors was found on 7.9.17 and 40 KB in bad sectors were found on 7.14.17. Is this an indication of a failing hard disk?

Here are the complete logs:

Checking file system on C:
The type of the file system is NTFS.

A disk check has been scheduled.
Windows will now check the disk.

CHKDSK is verifying files (stage 1 of 5).
478208 file records processed. File verification completed.
1878 large file records processed. 0 bad file records processed. 0 EA records processed. 61 reparse records processed. CHKDSK is verifying indexes (stage 2 of 5).
583188 index entries processed. Index verification completed.
0 unindexed files scanned. 0 unindexed files recovered. CHKDSK is verifying security descriptors (stage 3 of 5).
478208 file SDs/SIDs processed. Cleaning up 893 unused index entries from index $SII of file 0x9.
Cleaning up 893 unused index entries from index $SDH of file 0x9.
Cleaning up 893 unused security descriptors.
CHKDSK is compacting the security descriptor stream
52491 data files processed. CHKDSK is verifying Usn Journal.
35721200 USN bytes processed. Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5).
Read failure with status 0xc00000b5 at offset 0x4ec485000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x5020a5000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x5020a8000 for 0x1000 bytes.
Read failure with status 0xc00000b5 at offset 0x4ec485000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x5020a9000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x5020b6000 for 0x1000 bytes.
Windows replaced bad clusters in file 102769
of name \hiberfil.sys.
478192 files processed. File data verification completed.
CHKDSK is verifying free space (stage 5 of 5).
70478889 free clusters processed. Free space verification is complete.
Adding 7 bad clusters to the Bad Clusters File.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

610112508 KB total disk space.
327405044 KB in 362026 files.
192536 KB in 52494 indexes.
28 KB in bad sectors.
599364 KB in use by the system.
65536 KB occupied by the log file.
281915536 KB available on disk.

4096 bytes in each allocation unit.
152528127 total allocation units on disk.
70478884 allocation units available on disk.

Internal Info:
00 4c 07 00 41 53 06 00 d7 48 0b 00 00 00 00 00 .L..AS. H.
da 7b 00 00 3d 00 00 00 00 00 00 00 00 00 00 00 . 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .

Windows has finished checking your disk.
Please wait while your computer restarts.

7.14.17 Scan Disk:

Checking file system on C:
The type of the file system is NTFS.

A disk check has been scheduled.
Windows will now check the disk.

CHKDSK is verifying files (stage 1 of 5).
478208 file records processed. File verification completed.
1878 large file records processed. 0 bad file records processed. 0 EA records processed. 61 reparse records processed. CHKDSK is verifying indexes (stage 2 of 5).
583252 index entries processed. Index verification completed.
0 unindexed files scanned. 0 unindexed files recovered. CHKDSK is verifying security descriptors (stage 3 of 5).
478208 file SDs/SIDs processed. Cleaning up 21 unused index entries from index $SII of file 0x9.
Cleaning up 21 unused index entries from index $SDH of file 0x9.
Cleaning up 21 unused security descriptors.
Security descriptor verification completed.
52523 data files processed. CHKDSK is verifying Usn Journal.
33874664 USN bytes processed. Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5).
Read failure with status 0xc00000b5 at offset 0x1a94d3000 for 0x8000 bytes.
Read failure with status 0xc00000b5 at offset 0x1a94d9000 for 0x1000 bytes.
Windows replaced bad clusters in file 142092
of name \PROGRA~1\ALWILS~1\Avast5\defs\17071404\exts.dll.
478192 files processed. File data verification completed.
CHKDSK is verifying free space (stage 5 of 5).
70411656 free clusters processed. Free space verification is complete.
Read failure with status 0xc00000b5 at offset 0xb74cf000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0xb74d3000 for 0x1000 bytes.
Read failure with status 0xc00000b5 at offset 0xb8094000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0xb8098000 for 0x1000 bytes.
Replacing bad clusters in logfile.
Adding 3 bad clusters to the Bad Clusters File.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

610112508 KB total disk space.
327675568 KB in 362398 files.
192632 KB in 52524 indexes.
40 KB in bad sectors.
597652 KB in use by the system.
65536 KB occupied by the log file.
281646616 KB available on disk.

4096 bytes in each allocation unit.
152528127 total allocation units on disk.
70411654 allocation units available on disk.

Internal Info:
00 4c 07 00 d5 54 06 00 ca 4b 0b 00 00 00 00 00 .L. T. K.
da 7b 00 00 3d 00 00 00 00 00 00 00 00 00 00 00 . 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .

Windows has finished checking your disk.
Please wait while your computer restarts.

Chkdsk Stage 3 Error but «Chkdsk /f» Fails to Execute Repair at Windows Restart

enter image description here

Summary:
I have a volume corruption: Specifically, it is a chkdsk Stage 3 Error. At stage 3, Chkdsk verifies Security Descriptors and USN Journals. However, chkdsk /f repair fails to run at Windows restart.
Details:
I have run chkdsk . It reports no issues. However, when I run chkdsk /scan , which executes further checks on the NTFS file system, I am getting an error at Stage 3. Stage 3 of the chkdsk process verifies security descriptors and USN journals (USN = Unique Sequence Number). Chkdsk reports the following message:

‘Windows has found problems which must be fixed offline. Please run «chkdsk /f» to fix the issue.’

When I execute fsutil dirty query at the command prompt, I get the result:»

Volume C: is dirty

This means the dirty bit has been set for the volume, marking the drive as being corrupt and in need of a chkdsk repair. However, when I attempt to run chkdsk /f at the next reboot of Window, I get the message «Scanning and Repairing» but do not see any progress percentages to indicate that repair is taking place. Windows successfully boots and does so quickly further indicating that a repair did not run. When I run fsutil dirty query again, I find the dirty bit remains set and running chkdsk /scan continues to report the stage 3 error. I am seeing the «Scanning and Repairing Drive (c:) at every Windows start-up. Windows is detecting the dirty bit and attempting to run the repair at each start-up but fails to even commence the repair (as I do not see any progress indicators). One of the symptoms is that I am unable to take backups (specifically I use the legacy Windows 7 Backup which fails) as Windows reports the backup failed because my disk is corrupt. When backup fails due to volume corruption, it can I believe, suggest an issue with the NTFS USN journals (I’m only guessing). I have read that chkdsk /f and defrag can fail to run when there is an NTFS journal corruption and that a journal reset can resolve the issue. This can be done running the command fsutil usn deletejournal at the command prompt with administrator privileges. It may be necessary to apply the /d /n switches and also to recreate the journal afterward by running the command fsutil usn createjournal afterward. However, I do not know how safe it is to delete the journal. Furthermore, I am unsure about the switches: /d appears to disable the journaling. Is this permanent? I do not even know what this means. To recreate the journal various parameters need to be provided with the fsutil usn createjournal and I do not know what they should be or how to properly run that command. ALSO PLEASE NOTE: I AM SPECULATING HERE with deleting and recreating the NTFS journal as a possible solution. Can anyone please suggest any solutions to my issue. Thank you.

IqbalHamid
asked Apr 15, 2021 at 15:54
IqbalHamid IqbalHamid
123 1 1 silver badge 9 9 bronze badges

2 Answers 2

OK, for the benefit of others, I will provide you with all the knowledge I have acquired which has helped me to resolve this issue.

In my case chkdsk was failing to execute its repair on my machine at each Windows start-up. With the dirty bit set, Windows was trying to execute chkdsk /f at every boot, but the execution of the repair was failing. I suspect the reason for this may be that my computer is quite modern and has BitLocker encryption activated on the drive. Hence, when I restart my PC, chkdsk fails as the drive remains in a RAW and encrypted state at the time chkdsk is initiated. If I am correct, then this may prove to be an increasingly common problem as the sale of computers with encrypted drives becomes the norm. Microsoft also needs to revisit this issue. Its design of the way chkdsk works when executed on the primary drive, needs to be revisited due to encryption preventing chkdsk from running at Windows startup.

I followed the advise of @tsc_chazz and booted to the command prompt, then ran chkdsk /f from there. Bam! problem solved! I could not believe it, it worked! Of course as the drive was encrypted, I had to provide the 48 character encryption key (which I knew nothing about and had to obtain from Microsoft via aka.ms/myrecoverykey). In my first attempt I skipped the page asking for the recovery key (ie: bitlocker encryption key) and was receiving error messages when I tried to run chkdsk /f from the boot-to-command-prompt environment. Chkdsk failed stating the type of the volume is RAW and that chkdsk does not run on RAW volumes.

All of this also suggests that any attempt to run chkdsk on the drive when it is mounted externally, may also fail. So for example, if I were to boot to a USB recovery disk and ran chkdsk on my primary partition from this recovery environment, it too would fail because the drive remains encrypted. The way around this would be to turn off the BitLocker on the drive via the Control Panel, beforehand. See guide here. The drive’s decryption process can take a very long time. However, this step should not be necessary as booting to command prompt takes you to a different drive (X: in my case) thus allowing you to run chkdsk /f on your primary partition (usually the c: drive).

So in summary, booting to command prompt and entering the recovery key in the process to decrypt the drive, then running chkdsk /f from there fixed the problem for me. Also, there is no need to run chkdsk /r . This takes much, much longer (hours to days) and is usually not necessary as physical issues (bad clusters) are much less likely to be the culprit or cause of the corruption.

However, had this not worked, I would have recreated the NTFS file system’s USN journals. This is because a chkdsk Stage 3 corruption relates to a corruption of these journals -I would imagine a hiccup with the USNs (Update Sequence Numbers). It has been noted that such a corruption can itself be the cause of chkdsk failing to run. Corruption here, can also cause backups and Defragging to fail. When running a backup, such as the Windows 7 backup, you may see an error message saying something like.

The backup failed for the following files because they are on corrupted drive c:

To recreate the NTFS USN journals, first delete, then recreate the journal.

Deleting the Journal
You can delete the NTFS USN journal using.

fsutil usn deletejournal /d /n c: 

This can take hours to run and will «lock your PC» until completed if you use the /n switch. So alternatively you can leave out the /n switch and it will delete the journal in the background and across reboots if necessary.

The /d and /n switches are poorly documented. Microsoft documentations here conflicts with information presented when you query the use of the command at the command prompt:

enter image description here

Both are inaccurate! The command prompt documentation is wrong as BOTH switches delete the journal, not just the /d. The Microsoft webpage documentation is misleading because the journal is actually deleted rather than disabled. The switches dictate how it gets deleted.

Because deleting the journal can take a very long time, the switches allow you to control whether it runs in-process or out-of-process. The /n switch executes deletejournal in process locking the handle to it (think of it as «locking the computer»). This forces you to wait until it has completed. The /d switch executes out-of-process and allows you to continue working. Deleting the journal can take hours to run and will continue across successive reboots until it has been completed. I have seen people apply both switches together when they are mutually exclusive.

Deleting the journal is nearly always safe, but it can sometimes have consequences with backup processes. Applications that are using the journal will not see file changes between the last time the application ran and when the journal was deleted. Well-programmed applications will detect that the journal was deleted and will revert to an alternative method of finding changed files or recreate it. I would advise it is safe to delete despite the consequences because at worst, you will only compromise the incremental ability of the backup. You can still do a FULL backup and start again; at least your data is not lost!

Recreating The Journal
I am informed it is not necessary to manually recreate the journal as running a backup program such as the Windows-7 backup option via the Control Panel (despite its name this option is available on Windows 8/8.1 and 10 also) will automatically recreate the NTFS journal.

If you want to manually recreate the journal, then at the command prompt, run either:

fsutil usn createjournal m=536870912 a=67108864 C: 

. if you have a very large drive (4TB+ with 400,000+ files);

Or for smaller drives, with fewer files, run:

fsutil usn createjournal m=67108864 a=8388608 C: 

If you are curious where these figures come from, they are the number of bit states raised to a sufficient power that provides the size in bytes for the journal log. IE: These figures are 2^x which gives the precise size in bytes around the size you want. Journals are typically kept between 30Mb to 40MB in size. I have hence, gone up to the next highest available size (67Mb) for the maxSize (m) parameter:

2^25 bytes x 2 = 33Mb x 2 = 67Mb

The allocationDelta (a) parameter needs to be around 1/8 of m, which is around 8Mb. You will not find this explanation anywhere else on the internet. Microsoft especially, have shamefully failed to adequately document the use of these two journal commands.

FYI: You can query the current size of your journals, by typing the following command at a command prompt with elevated privileges:

C:\Windows\system32> fsutil usn queryjournal C: 

You will get an output similar to this:

enter image description here

The a and m parameters are provided in BYTES, in hexadecimal. For my Windows 8.1 PC with a 2TB primary partition, the values equate to:

m = 33,554,432 bytes = 33Mb

a = 8,388,608 bytes = 8Mb

You can query the number of files on your system by executing the following command at a command prompt with elevated privileges:

C:\Windows\system32> dir C:\ /s /a /w 

You will see an output like this.

enter image description here

Add the number of files and directories together for the total amount; 1,616,718 in this example.

You can then use the following table (reproduced from this page ) as an alternative guide to find the appropriate values for Maximum Size and Allocation Delta.

enter image description here

See guide to creating journals here: See also some good advice here:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *