Ferramenta para reparar diário MFT ou NTFS em um disco que sofreu falha na hibernação

Ferramenta para reparar diário MFT ou NTFS em um disco que sofreu falha na hibernação

Eu li algumas postagens relacionadas a partições NTFS corrompidas ou que não funcionam, mas sem uma solução adequada para o meu caso. Aqui está: meu sistema é

  • SSD no miniPCI expresso(PCIe), com Windows 7 instalado. Duas partições: uma com utilitários Dell (40 MB), o restante com a própria instalação do Windows (119 GB).
  • HDD com 450 GB de arquivos NTFS e 30 GB de todas as partições que fazem uma instalação do Ubuntu funcionar (swap, sistema, etc.)

O dispositivo de inicialização é o HDD interno (IRRT), o único possível; isso ativa o IRRT e iniciaGRUB, que ao apontar para algum setor no HDD pode iniciar o Windows 7 no SSD.

Agora o que aconteceu:

Coloquei meu computador em suspensão e ele entrou em hibernação depois de algumas horas. A placa wireless foi fisicamente desativada (Dell M4600). Então liguei o laptop e, antes que o GRUB fosse concluído, liguei a placa wireless novamente. Em seguida, pressionei "windows" no GRUB. EntãoBSOD, reinicie e o Windows não consegue encontrar a partição de inicialização: "dispositivo necessário ausente".

Eu tentei o disco de recuperação do Windows 7: só consigo reparar um pouquinho da instalação do Windows que está no HDD, não consigo ver o SSD. O "reparo" não faz nada. Remover o disco rígido para contornar o GRUB à força não fez com que o DVD do Windows visse o setor de inicialização do SSD. Não bastou uma “instalação do Windows”.

Agora, se eu começar a agir como se fosse instalar o Windows novamente, o Windows vê as duas partições na unidade C, elas ainda estão aqui, em NTFS.

Então fui para o Linux e tenteifdisk: as partições ainda estão aqui, novamente. Mas eles não aparecem emNáutilo, e não consigo montá-los. No entanto,ddposso recuperar dados: se eu tentar ler dados em algum grande deslocamento aleatório (como deslocamento de 20 GB e ler 10 blocos), os blocos são de fato "dados", não há problema para acessar fisicamente a unidade, não parece ter falhado completamente pelo menos. Farei um backup amanhã então.

tenteiTestDisk: os setores de inicialização são idênticos e parecem OK, mas ambosMFTmostrar como "ruim", nada mais. Não é possível acessar os arquivos dentro do sistema de arquivos.

Nesse site, vi algo sobre uma escrita erradaRegistro no diário NTFS,Precisa recuperar partição NTFS corrompida.

Quase última postagem. Nada sobre isso na Internet, pelo que pesquisei.

E suspeito que algo sobre o processo de hibernação não seja revertido, pois lembro que o processo de hibernação altera muito a sequência de inicialização (ou então você poderia mover hiberfil.syssem problemas, mas não pode. Precisa estar no diretório raiz, porque não há lugar no carregador de boot para acomodar um local de pasta ou mesmo outra unidade!).

Então talvez ambos os setores de inicialização tenham sido afetados pela hibernação, e quando não conseguiu concluir o processo de reversão para inicialização normal, ficou assim, o Windows olha para onde o ponteiro de inicialização aponta e não reconhece uma instalação normal do Windows e se recusa a repará-lo , e como o Linux não consegue encontrar o MFT, ele não consegue montá-lo... ou talvez algo diferente, afetando o próprio MFT. Não sei... vou tentarCHKDSKe, após o backup,fixmbr, do DVD do Windows 7.

ATUALIZAÇÃO: fixmbr e fixboot parecem funcionar apenas no console de recuperação e não consegui acessá-lo. No DVD do Windows 7, eu poderia fazer o CHKDSK: ele apenas dizia que o volume era NTFS antes de travar porque "MFT corrompido. Tentarei reparar. MFT não pôde ser reparado. Saia do chkdsk".

Ao tentar o diskpart, minha partição no SSD foi vista como... Raw. Portanto, isso não corresponde ao que o CHKDSK viu.

Algo está estranho em tudo isso: durante todo esse tempo, o Windows não viu os primeiros 40 MB do meu SSD, que continha utilitários Dell. No Windows 7 Explorer, a partição principal do SSD sempre foi C:\, e a partição do HDD foi D:\: essa partição de 40 MB no SSD nunca apareceu em lugar nenhum. Mas agora, o Windows vê essa partição de 40 MB e dá a C:\letra. Enquanto a D:\letra corresponde à partição de 119 GB, formato “Raw”, não podendo ser lida. eu não entendo nada...

Responder1

O dispositivo de boot é o Internal HDD (IRRT), o único possível; isso habilita o IRRT e inicia o GRUB, que porapontando para algum setorno HDD pode iniciar o Windows 7 no SSD. Acho que você precisa que o ponteiro seja o mesmo, é este.^

Estou supondo {Então pressionei "windows" no GRUB. Então BSOD, reinicie e o Windows não consegue encontrar a partição de inicialização: "dispositivo necessário ausente". }

não está usando o mesmo ponteiro, especialmente se entrar em hibernação. a inicialização do grub teria que apontar para o setor de inicialização do Windows ou o hiberfil.sys teve um problema semelhante quando tentei editar o winresume.exe para tentar apontar para D: quando o Windows está em C: ele não tiraria o Windows da hibernação, quando usei a cópia do original foi consertado.

espero que isto ajude

Responder2

Por fim, reinstalei o Windows na unidade C (o SSD) e, quando foi concluído, o sistema funcionou novamente, mas a sequência de inicialização causou um curto-circuito no GRUB. Então agora, a instalação do Linux está fora de alcance.

Ele ainda está no meu disco D e sei que teria apenas que inserir um live CD e reparar o GRUB para que funcionasse, mas ainda não fiz isso, por outros motivos.

Já se passou um ano e, de vez em quando, aconteciam outros BSODs ao sair da hibernação, mas nunca mais causaram qualquer dano permanente ao sistema de arquivos.

Acho que estudar tudo sobre a resposta da inicialização está certo de alguma forma. todo o processo "inicialização no HDD (IRRT) -> GRUB -> Ponteiro correto para o bootloader do Windows-> localização da sequência de inicialização" fora da hibernação "" deve ter falhado em algum lugar, de uma maneira que nenhuma ferramenta de reparo convencional poderia consertar.

No final, não consegui entender o problema e agora meu sistema foi reinstalado, então provavelmente nunca terei pistas adicionais sobre o que aconteceu. Se um dia eu tiver conhecimento suficiente sobre o processo de inicialização, IRRT, Windows, GRUB e a configuração especial do disco que possuo, posso acabar adivinhando uma explicação melhor.

Mas por enquanto, direi o seguinte: aparentemente, nesta configuração precisa (Dell M4600), ter GRUB em IRRT com Linux no disco rígido "real" e windows em um SSD mini-PCI-express, com hibernação ativada, parece inseguro, porque os BSODs ainda acontecem mesmo com o GRUB desabilitado (o que significa que todo o processo de inicialização é controlado pelo Windows agora, e mesmo com isso, pode haver problemas para sair da hibernação - talvez o tamanho dos 12 GB de RAM e, portanto, 9 GB do hyberfil .sys, desempenha um papel aqui), e como um desses BSODs poderia matar minha partição NTFS na minha configuração anterior, sem qualquer falha de hardware (porque meu SSD ainda funciona muito bem - não verifiquei sua integridade em detalhes profundos, embora), não vejo por que isso não poderia acontecer novamente.

Portanto, a solução existe e não é muito agradável, mas o paradeiro desta questão precisa ainda não está claro. Se alguém tiver mais informações aqui, ficaria muito feliz em ouvi-las.

informação relacionada