Device harddiskvolume2 ошибка

When working with Windows operating systems, it’s common to encounter error messages that reference specific hard disk volumes, such as \Device\HarddiskVolume3. These references may seem confusing at first, but they’re actually quite simple to understand and use.

In this article, we’ll explain what these references mean and provide a comprehensive guide on how to tell which drive each hard disk volume refers to in Windows 11 or Windows 10. The step-by-step instructions will enable you to locate the specific device or volume path needed to resolve any file access events issues.

Understanding Hard Disk Volume References

Before we dive into how to find hard disk volume references in Windows, it’s important to understand what they are and why they’re used.

Also see: How to Hide a Drive in Windows 11

In Windows, hard disk volumes are used to organize data on physical hard drives. Each volume is assigned a unique reference, such as:

• \Device\HarddiskVolume3
• \Device\HarddiskVolume4
• \Device\HarddiskVolume5
• \Device\HarddiskVolume1
• \Device\HarddiskVolume2
• \Device\HarddiskVolume6

This reference is used to identify the volume and access its contents.

When troubleshooting issues with Windows, you may encounter error messages that reference a specific hard disk volume. For example, you might see an error message like this:

\Device\HarddiskVolume3\Windows\System32\svchost.exe is missing or corrupted

This error message is telling you that the Windows operating system can’t find the svchost.exe file on the third hard disk volume. To fix the issue, you’ll need to locate the volume and the file.

Related issue: Service Host Local System (svchost.exe) High CPU, Disk or Memory Usage

How to tell which drive is \Device\HarddiskVolume3 or other volumes?

Now that we understand what hard disk volume references are, let’s take a look at how to find the hard disk volume number and tell which drive each volume is referring to in Windows 11/10.

Method 1: Listing all drive letters and hard disk volume numbers using PowerShell

This method provides you with a comprehensive list of all device names and their corresponding volume paths on your local machine. It leverages PowerShell to query the Windows Management Instrumentation (WMI) class Win32_Volume for the drive letter and then uses the QueryDosDevice function from the Kernel32 module to obtain the device path.

To list all the drive letters and their corresponding hard disk volume numbers on your Windows system, follow these steps:

1. Open Notepad and paste the following PowerShell script:

   $DynAssembly = New-Object System.Reflection.AssemblyName('SysUtils')
   $AssemblyBuilder = [AppDomain]::CurrentDomain.DefineDynamicAssembly($DynAssembly, [Reflection.Emit.AssemblyBuilderAccess]::Run)
   $ModuleBuilder = $AssemblyBuilder.DefineDynamicModule('SysUtils', $False)
    
   $TypeBuilder = $ModuleBuilder.DefineType('Kernel32', 'Public, Class')
   $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod('QueryDosDevice', 'kernel32.dll', ([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static), [Reflection.CallingConventions]::Standard, [UInt32], [Type[]]@([String], [Text.StringBuilder], [UInt32]), [Runtime.InteropServices.CallingConvention]::Winapi, [Runtime.InteropServices.CharSet]::Auto)
   $DllImportConstructor = [Runtime.InteropServices.DllImportAttribute].GetConstructor(@([String]))
   $SetLastError = [Runtime.InteropServices.DllImportAttribute].GetField('SetLastError')
   $SetLastErrorCustomAttribute = New-Object Reflection.Emit.CustomAttributeBuilder($DllImportConstructor, @('kernel32.dll'), [Reflection.FieldInfo[]]@($SetLastError), @($true))
   $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)
   $Kernel32 = $TypeBuilder.CreateType()
    
   $Max = 65536
   $StringBuilder = New-Object System.Text.StringBuilder($Max)
    
   Get-WmiObject Win32_Volume | ? { $_.DriveLetter } | % {
   	$ReturnLength = $Kernel32::QueryDosDevice($_.DriveLetter, $StringBuilder, $Max)
   	
   	if ($ReturnLength)
   	{
   		$DriveMapping = @{
   			DriveLetter = $_.DriveLetter
   			DevicePath = $StringBuilder.ToString()
   		}
   		
   		New-Object PSObject -Property $DriveMapping
   	}
   }
   

   

2. Save the Notepad file with a .ps1 extension, such as List-drives-and-hard-disk-volumes.ps1.
3. Run the List-drives-and-hard-disk-volumes.ps1 script from PowerShell to list all drive letters and their corresponding hard disk volume paths on your Windows 11 or Windows 10 system.

Recommended resource: Run CMD, PowerShell or Regedit as SYSTEM in Windows 11

To run the List-drives-and-hard-disk-volumes.ps1 script from PowerShell, follow these steps:

1. Open PowerShell with administrative privileges: Right-click on the Start button or press Win + X and then click on “Windows PowerShell (Admin)” or “Windows Terminal (Admin)” if you are using Windows Terminal. Click “Yes” on the User Account Control (UAC) prompt to grant administrative access.
2. Change the execution policy (if needed): By default, PowerShell may not allow you to run scripts due to its restrictive execution policy. To change the execution policy, type the following command and press Enter:

   Set-ExecutionPolicy RemoteSigned

   When prompted, type Y and press Enter to confirm the change. This command allows you to run scripts that you created or downloaded from the internet, as long as they are signed by a trusted publisher.

3. Navigate to the script’s location: Use the cd command to navigate to the directory where you saved the “List-drives-and-hard-disk-volumes.ps1” script. For example, if you saved the script in the Desktop directory, type the following command and press Enter:

   cd C:\Users\username\Desktop

   Replace the username with your actual user name in your Windows system.

4. Run the script: Type the following command and press Enter to run the List-drives-and-hard-disk-volumes.ps1 script:

   .\List-drives-and-hard-disk-volumes.ps1

   The script will execute and display the device names and their corresponding volume paths for all the drives on your local machine.

5. Set the execution policy back to its default value: After running the script, it’s recommended to set the execution policy back to its default value. To do this, type the following command and press Enter:

   Set-ExecutionPolicy Restricted

   

Remember, you need to have administrative privileges to run the script, as it accesses system-level information.

Useful tip: How to Merge Two Drives in Windows 11

Here’s a more detailed explanation of what the script does:

1. The script first creates a dynamic assembly called ‘SysUtils’ and defines a P/Invoke method for calling the QueryDosDevice function from the Kernel32 module.
2. It sets the maximum length of the StringBuilder object to 65536, which allows it to store the device path information.
3. The script then uses Get-WmiObject to query the Win32_Volume class for drive letter information. It filters the results to include only objects with a drive letter.
4. For each drive letter, the script calls the QueryDosDevice function with the drive letter as the input. The function returns the length of the device path string, which is then used to create an object containing the drive letter and device path.
5. Finally, the script outputs the device letter and device path for each drive.

Similar problem: Hard Drive Doesn’t Show Up After Clone in Windows 11

Method 2: Getting the hard disk volume number from a specific drive letter using PowerShell

This method allows you to find the device path for a specific drive letter by using a similar approach as Method 1. However, instead of listing all the device names and their corresponding volume paths, this method prompts you for a single drive letter and returns its device path.

To display the device path for a given device name (drive letter), use the following PowerShell script:

1. Open Notepad and paste the following PowerShell script:

   $driveLetter = Read-Host "Enter Drive Letter:"
   Write-Host " "
   $DynAssembly = New-Object System.Reflection.AssemblyName('SysUtils')
   $AssemblyBuilder = [AppDomain]::CurrentDomain.DefineDynamicAssembly($DynAssembly, [Reflection.Emit.AssemblyBuilderAccess]::Run)
   $ModuleBuilder = $AssemblyBuilder.DefineDynamicModule('SysUtils', $False)
    
   $TypeBuilder = $ModuleBuilder.DefineType('Kernel32', 'Public, Class')
   $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod('QueryDosDevice', 'kernel32.dll', ([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static), [Reflection.CallingConventions]::Standard, [UInt32], [Type[]]@([String], [Text.StringBuilder], [UInt32]), [Runtime.InteropServices.CallingConvention]::Winapi, [Runtime.InteropServices.CharSet]::Auto)
   $DllImportConstructor = [Runtime.InteropServices.DllImportAttribute].GetConstructor(@([String]))
   $SetLastError = [Runtime.InteropServices.DllImportAttribute].GetField('SetLastError')
   $SetLastErrorCustomAttribute = New-Object Reflection.Emit.CustomAttributeBuilder($DllImportConstructor, @('kernel32.dll'), [Reflection.FieldInfo[]]@($SetLastError), @($true))
   $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)
   $Kernel32 = $TypeBuilder.CreateType()
    
   $Max = 65536
   $StringBuilder = New-Object System.Text.StringBuilder($Max)
   $ReturnLength = $Kernel32::QueryDosDevice($driveLetter, $StringBuilder, $Max)
    
    if ($ReturnLength)
    {
        Write-Host "Device Path: "$StringBuilder.ToString()
     }
     else
     {
         Write-Host "Device Path: not found"
     }
   Write-Host " "
   

   

2. Save the Notepad file with a .ps1 extension, such as Get-device-path-from-drive-letter.ps1.
3. Run the Get-device-path-from-drive-letter.ps1 script from PowerShell. When prompted, enter the drive letter for which you want to retrieve the device path.

To learn how to run the .ps1 PowerShell script you’ve created, follow the instructions as stated in the previous method.

Here’s an overview of what the script does:

1. As in Method 1, the script creates a dynamic assembly called ‘SysUtils’ and defines a P/Invoke method for calling the QueryDosDevice function from the Kernel32 module.
2. The script prompts you to enter a drive letter by using the Read-Host command. Make sure to enter the drive letter without a trailing backslash (e.g., “C:”, not “C:\”).
3. It sets the maximum length of the StringBuilder object to 65536, allowing it to store the device path information.
4. The script calls the QueryDosDevice function with the input drive letter. If the function is successful, it returns the length of the device path string.
5. If the QueryDosDevice function is successful, the script outputs the device path for the input drive letter. Otherwise, it displays a message indicating that the device path was not found.

Summary

These two methods provide flexible options for obtaining the hard disk volumes information in Windows 11 or 10. Method 1 is useful when you need a comprehensive list of all drive letters and their corresponding volume paths, while Method 2 is more targeted, allowing you to retrieve the hard disk volume path for a specific drive letter. Both methods use PowerShell scripts, making it easy to integrate them into your system management or troubleshooting workflows.

Назвать точную причину, из-за которой возникает данная ошибка невозможно. В официальной документации от Microsoft по данной ошибке весьма внушительный список вероятных ошибок и неисправностей. Одно понятно: есть проблема с загрузчиком Windows 10. Предположим, что структура разделов диска не пострадала и доступна, файловая система так же доступна. Как это узнать? Загрузиться с установочного диска Windows 10 или среды восстановления Windows PE и получить доступ к разделам на диске.

Предположим, что загрузились с установочного диска (флешки) Windows 10. Запускаем командную строку сочетанием клавиш Shift+F10. Убедимся, что диск исправен.

chkdsk.exe <N>: /F /R /X — <N> буква диска, на который установлен Windows

Проверка может занять продолжительное время. Для обладателей SSD/nvme накопителей существенно меньше. Если всё исправно, то ответ должен быть приблизительно следующим.

Хорошо, значит кроме загрузчика данные не повреждены. Т.е. нет надобности переустанавливать Windows. Следующим шагом надо посмотреть структуру разделов (томов) на диске. Делается это с помощью команды diskpart.exe. Всё в той же, ранее открытой, командной строке выполним следующие команды.

diskpart
list disk
sel disk N - где N номер вашего диска
list vol

Последняя команда отобразит список разделов (томов) на диске. Из этого списка необходимо выбрать раздел (том), на котором находится загрузчик. Как? Относительно просто. Согласно документации от Microsoft, в статье UEFI/GPT-based hard drive partitions, раздел System partition, загрузчик (EFI System Partition или ESP) будет лежать на разделе с файловой системой FAT32, а размер такого раздела (тома) вряд ли будет превышать 500 мегабайт. Например, на моём диске раздел занимает всего лишь 260 мегабайт.

Хорошо бы посмотреть, что осталось от загрузчика и остался ли он вообще. Для этого необходимо выполнить следующие команды.

diskpart
list disk
sel disk N - где N номер вашего диска
list vol
sel vol N - где N номер вашего вашего EFI раздела
list vol - проверка, что выбран нужный раздел, будет помечен *
assign letter=N - назначаете букву диска отличимую от используемых. Например, D
remove letter=N - если потребуется удалить букву диска

Чтобы выйти из diskpart наберите команду exit. Теперь, чтобы попасть на диск D, необходимо выполнить следующую команду.

DISKPART> exit
C:\ D:

В корне раздела (тома) должен находиться только каталог EFI. Внутри него будут находиться директории Boot и Microsoft, возможно, будут находиться ещё какие-то. Нас интересует только директория Microsoft и всё содержащееся внутри неё. Для этого можно прибегнуть к паре способов. Лично я выбираю самый простой.

D:\dir EFI\Microsoft\Boot

Нас интересует наличие 2 файлов: BCD и bootmgfw.efi. Плохая новость в том, что записи в них могут быть нарушены или сами файлы могут быть повреждены. Проверить это можно выполнив соответствующую команду.

C:\bcdedit /enum

Ответ должен быть приблизительно следующим.

Нас интересуют только поля device partition и path в Диспетчере загрузки Windows. Данные поля являются посредниками между BIOS и основным загрузчиком Windows.

• device partition отвечает за раздел (том), на котором лежит загрузчик.

• path отвечает за путь до загрузчика.

Как уже выше было написано файлы могут повреждены или отсутствовать вовсе. В данной ситуации я не рекомендую погружаться в дебри редактирования полей BCD файла. Предлагаю пойти по пути наименьшего сопротивления, а именно. Загрузим в данную директорию новый загрузчик, пересоздадим файл BCD и загрузимся в Windows, из которого в свою очередь можно редактировать файл BCD графическими утилитами навроде Visual BCD Editor, EasyBCD, BootICE. В данной статье я не буду рассматривать как редактировать приведёнными программами файл BCD.

Прежде чем копировать новый загрузчик и файл BCD я рекомендую удалить всё содержимое. Дабы избежать в будущем ошибок навроде 0x00000001, которая даст понять, что основной загрузчик Windows не найден.

Выполнить удаление можно с помощью следующих команд.

D:\erase /f /s /q EFI # удаляет все файлы
D:\rmdir /s /q EFI # удаляет все каталоги

Ранее скрытому разделу EFI была присвоена буква D, но после перезагрузки эта связь пропадёт и загрузчик не будет знать с какого раздела производить загрузку. Поэтому в поле device partition необходимо указать запись в виде \Device\HarddiskVolumeN — вместо N номер раздела (тома). Возможно вы уже обратили внимание на то, что N раздела (тома) совпадает с N раздела (тома) отображаемого в diskpart. Запомните это значение. Копируем новый загрузчик.

bcdboot C:\Windows /l ru-ru /s D: /f UEFI

Редактируем вновь созданное хранилище данных конфигурации системы (файл BCD).

bcdedit /v

В выводе команды нас интересует только раздел {bootmgr} и его значения идентификатор, device partition и path. Скопируйте GUID идентификатор.

идентификатор {9dea862c-5cdd-4e70-acc1-f32b344d4795} <----- GUID
device partition=\Device\HarddiskVolume2
path \EFI\Microsoft\Boot\bootmgfw.efi

Редактируем файл BCD указав раздел (том). Не забудьте изменить цифру в конце HarddiskVolume, которую я рекомендовал запомнить выше.

bcdedit /set {9dea862c-5cdd-4e70-acc1-f32b344d4795} device partition=\Device\HarddiskVolume2

Проверяем, что изменения применились.

bcdedit /enum

В поле device partition должен быть указан \Device\HarddiskVolume2. Теперь можно перезагружать компьютер и пробовать загружаться в установленную Windows. Если вы сделали всё правильно, то Windows успешно загрузится.

Если у вас отсутствует раздел EFI, то не беда, загрузчик можно положить в корень диска с установленной системой. Ниже приведён пример такой команды.

bcdboot C:\Windows /l ru-ru /s C: /f UEFI

В случае успеха в корне диска C у вас появится папка EFI. После этого следует изменить хранилище данных конфигурации системы (файл BCD), где теперь лежит загрузчик ОС.

Получаем идентификатор {bootmgr}, раздел, в который будет вноситься изменение.

bcdedit /v

В моём примере вывод будет следующим, GUID идентификатор уникален и будет отличаться.

идентификатор {9dea862c-5cdd-4e70-acc1-f32b344d4795} <----- GUID
device partition=\Device\HarddiskVolume2
path \EFI\Microsoft\Boot\bootmgfw.efi

Параметр идентификатор то, что нам нужно. Копируем GUID значение. Далее редактируем раздел (том) в файле BCD указав, что корнем раздела будет являться диск C.

bcdedit /set {9dea862c-5cdd-4e70-acc1-f32b344d4795} device partition=C:

В случае успеха появится сообщение: операция успешно завершена. Чтобы убедиться, что изменения применились выполните следующую команду.

bcdedit /enum

В выводе команды обратите внимание на секцию {bootmgr} device partition, значением должно быть C:

Теперь можно перезагружать компьютер и пробовать загружаться в установленную Windows. Если вы сделали всё правильно, то Windows успешно загрузится.

Дополнительные команды, которые могут быть полезны в процессе восстановления загрузчика.

diskpart create partition EFI size=N — создать раздел EFI на диске
bootrec.exe ключи /RebuildBcd, /ScanOs, /FixBoot
mountvol.exe ключ /S представляет интерес
DriveLetterView показывает \Device\HarddiskVolumeN, удобна только при использовании в LiveCD.

Метки: bcd, bootloader, efi, Windows 10

This entry was posted on 2022/01/07 at 12:00:00 and is filed under Software. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

Я получаю следующие ошибки в журнале событий безопасности на компьютере с Windows 7 x32.

Есть несколько из них, и я беспокоюсь, что это может указывать на предстоящий сбой диска.

Правильно ли я беспокоиться? Событие ниже:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          12/16/2010 9:12:33 AM
Event ID:      5038
Task Category: System Integrity
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      ThisMachineName
Description:
Code integrity determined that the image hash of a file is not valid.  The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name:  \Device\HarddiskVolume2\Windows\System32\drivers\DGIVECP.SYS    
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>5038</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12290</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2010-12-16T15:12:33.026367100Z" />
    <EventRecordID>32974</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="44" />
    <Channel>Security</Channel>
    <Computer>ThisMachineName</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">\Device\HarddiskVolume2\Windows\System32\drivers\DGIVECP.SYS</Data>
  </EventData>
</Event>

РЕДАКТИРОВАТЬ

Было несколько разных с одной и той же проблемой: Имя файла: \Device \HarddiskVolume2 \Windows \System32 \drivers \SSPORT.SYS Имя файла: \Device \HarddiskVolume2 \Windows \System32 \drivers \CVPNDRVA.sys

CVPNDRVA относится к программному обеспечению Cisco VPN. Я полагаю, что и DGIVECP, и SSPORT связаны с принтером Samsung.

Я посмотрел дольше, и похоже, что только эти три драйвера упоминаются.