Questão Processo de inicialização do Windows 2008 R2


Eu fiquei perplexo tentando entender algum comportamento que estou experimentando e esperava que alguém lá fora ajudasse a me esclarecer um pouco.

Eu acho que minha pergunta se resume a isso: Especificamente, como o processo de inicialização do Windows determina a localização de um VBR / bootsector no disco para a partição 'boot' no Windows 2008 R2?

O pano de fundo da minha pergunta é o seguinte.

Eu tenho uma instalação perfeitamente feliz, funcionando de 2008R2 (VM) que contém a partição reservada do sistema 100 MB padrão, seguido pelo 'boot' (C:\) partição. Para fins educacionais, mudei o C:\ partição exatamente 1MB para o "direito" da partição do sistema (usando gparted), que inseriu um intervalo de 1MB (2048 setor) entre as duas partições.

Este processo atualizou corretamente a entrada da partição no MBR, bem como modificou o C:\ campo "setor reservado / oculto" do setor de inicialização.

Mas agora o Windows não inicializa (dá um erro no Boot Manager "0xc0000225"- um dispositivo necessário está inacessível.). E uma instalação de reparo não pode nem encontrar a instalação do Windows para reparar. Lembre-se, se eu montar a unidade em outra máquina Windows, os volumes são saudáveis ​​e viáveis. C:\ Particionar de volta ao seu lugar original, tudo inicializa.

Então, dado que o MBR está apontando para o offset correto, por que o Windows não consegue encontrar / carregar o C:\ partição quando foi movido?


2


origem


Presumivelmente, o gparted inseriu uma partição vazia entre as duas partições NTFS, então talvez o gerenciador de inicialização esteja tentando inicializar a segunda partição, que agora está vazia? Você já tentou usar bcdboot (quando a unidade está montada na outra máquina) para reparar a entrada de inicialização? - Harry Johnston
@Harry Johnston- Obrigado pela resposta. Verificar o MBR revela que existem apenas duas partições, apenas com uma lacuna entre elas. Eu não usei o bcdboot explicitamente, mas acho que a inicialização do Windows RE tentou e falhou. No entanto, estou mais interessado em saber por que isso está acontecendo do que corrigi-lo (visto que eu o interrompi intencionalmente em primeiro lugar) - James
Não tenho certeza se ter um intervalo entre as partições é permitido. O que acontece se você criar explicitamente uma nova partição no intervalo? Eu também sugiro tentar bcdboot explicitamente, com base no fato de que saber o que conserta ou não o comportamento fornece informações sobre as possíveis causas. - Harry Johnston
@Harry Johnston- Acontece que foi uma boa dica, obrigado. Executando manualmente o bcdboot em um prompt de comando do Windows RE fez corrigir o problema. O que é estranho é que não parece alterar o MBR ou o Bootsector para a segunda partição (todos os valores são os mesmos). Vou tentar reverter e fazer uma pequena partição para fora do 'gap' e ver qual o efeito que vem a seguir. Então isso significa que a 'partição do sistema' e / ou o BCD contêm um deslocamento de setor para a localização do VBR? Não consigo encontrar isso em nenhuma documentação, mas parece ser o comportamento que estou vendo. - James


Respostas:


Primeiramente, você deve observar que o VBR na partição C: não está envolvido no processo de inicialização. O VBR na partição "system" carrega o bootmgr, que carrega o kernel do Windows a partir da partição C :.

Eu apenas tentei isso sozinho. Convenientemente, verifica-se que executar o bcdboot gera uma nova entrada de inicialização no BCD, para que possamos comparar facilmente a entrada antiga com a nova para ver o que foi alterado.

Usando o bcdedit, podemos ver que as opções device e osdevice são diferentes:

C:\Windows\system32>bcdedit /enum /v

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-us
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {fde483f1-1482-11e2-90a1-00505698002c}
resumeobject            {fde483f0-1482-11e2-90a1-00505698002c}
displayorder            {fde483f1-1482-11e2-90a1-00505698002c}
                        {7409376c-f38e-11e1-bc89-00505698002c}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {fde483f1-1482-11e2-90a1-00505698002c}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-us
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
osdevice                partition=C:
systemroot              \Windows
resumeobject            {fde483f0-1482-11e2-90a1-00505698002c}
nx                      OptIn
detecthal               Yes

Windows Boot Loader
-------------------
identifier              {7409376c-f38e-11e1-bc89-00505698002c}
device                  unknown
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {7409376d-f38e-11e1-bc89-00505698002c}
recoveryenabled         Yes
osdevice                unknown
systemroot              \Windows
resumeobject            {7409376b-f38e-11e1-bc89-00505698002c}
nx                      OptIn

Infelizmente, o bcdedit não nos informa como as informações são armazenadas, portanto, teremos que examinar o próprio arquivo BCD. Como você já deve saber, o arquivo BCD é, na verdade, uma seção de registro e normalmente é carregado em HKLM\BCD00000000, então podemos examiná-lo com regedit ou usando reg export.

O identificador de cada entrada é o nome da chave do registro que contém as configurações. As configurações em si são subchaves, organizadas na mesma ordem em que aparecem na saída do bcdedit. Acontece (sem surpresa) que em cada entrada, dispositivo e dispositivo os contêm os mesmos dados, e esses dados são diferentes para a entrada de funcionamento do que para o antigo.

No meu sistema, isso aparece na entrada em funcionamento:

"Element"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,06,00,00,00,00,\
  00,00,00,48,00,00,00,00,00,00,00,00,00,80,06,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,01,00,00,00,b0,5d,de,33,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,00

e isso aparece na entrada antiga:

"Element"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,06,00,00,00,00,\
  00,00,00,48,00,00,00,00,00,00,00,00,00,50,06,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,01,00,00,00,b0,5d,de,33,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,00

Há apenas uma diferença. Vamos formatar a entrada antiga um pouco mais bem:

0000 00,00,00,00,00,00,00,00,
0008 00,00,00,00,00,00,00,00,
0010 06,00,00,00,00,00,00,00,
0018 48,00,00,00,00,00,00,00,
0020 00,00,50,06,00,00,00,00,
0028 00,00,00,00,00,00,00,00,
0030 00,00,00,00,01,00,00,00,
0038 b0,5d,de,33,00,00,00,00,
0040 00,00,00,00,00,00,00,00,
0048 00,00,00,00,00,00,00,00,
0050 00,00,00,00,00,00,00,00

Na nova entrada, o byte 0x0022 é 0x80 em vez de 0x50. Acontece que eu mudei a partição por 3MB, então eu suspeito que isso seja parte de um offset. Vamos ver o que acontece se eu mover outros 4MB (para um total de 7MB) e criar uma nova entrada BCD, vamos? OK ... o 0x80 se torna 0xC0, então isso é consistente.

Um palpite sensato seria que os oito bytes (ou talvez dezesseis?) A partir de 0x0020 são o deslocamento de byte do início da partição. O valor de 0x06C00000 é 113246208 ou exatamente 108 MB; Examinando a tabela de partição, acho que é realmente o início da partição. QED. :-)


1



Além disso, os quatro bytes em 0x0038 são a assinatura do disco (que pode ser encontrada em 0x01b8 no MBR). - Harry Johnston
Woah, isso é fantástico, e explica exatamente o que eu estava vendo. Você, Sr. Johnston, é meu novo herói. - James