73 replies to this topic

[Anon10]

This:

cat --hex (hd0)+1

rather than either of these:

cat --hex (hd0)128+1

cat --hex (hd0)2048+1

 resulted in what you said it would (EB ... NTFS).

Edited by Anon10, 10 November 2014 - 07:39 PM.

[Wonko the Sane]

My bad, I completely missed the post where you specified the model, is it this one?

http://www.bestbuy.c...4&skuId=1902435

model MZ-7TE250BW or KW?

Anyway they should be 256 Gib in size (the data you posted initially about Sector Count/Size, which amount roughly to 8 Gib, are probably due to the "outadated" grub4dos version you have installed).

 

I'll wait for the result of the issued commands, before suggesting next possible step.

 

FORGET about any previously suggested command. 

 

If you found the "NTFS" running::

cat --hex (hd0)+1

as you seem to have , just try running:

root (hd0)
ls

and report what you see ....

 

Wonko 

[steve6375]

I have a MZ7TE250HMHP

Samsung SSD 840 EVO 250G  F/W Rev.=EXT0 
Reported size 250,059,350,016 bytes (232.8859GiB)  Last LBA 488,397,167

[Wonko the Sane]

I have a MZ7TE250HMHP

Samsung SSD 840 EVO 250G  F/W Rev.=EXT0 
Reported size 250,059,350,016 bytes (232.8859GiB)  Last LBA 488,397,167

Very good.

So we have now a much more narrow "target" for next cat --hex attempt (if it will be needed), thanks

 

It is still not at all clear to me how the thingy was setup (or how could it work) initially i.e. if - from the beginning - the SSD was a "superfloppy" (as I doubt that the stupid loader may have re-partitioned/formatted anything). (and if this is the case there won't probably be a backup bootsector anyway )

 

Wonko

[Anon10]

I don't know which one of those my SSD is. Anyway, this is what I got from the first command:
Filesystem type is ntfs, using whole disk

And this from the second:
Program\ Files\ (x86) Users Autodesk Boot bootmgr BOOTSECT.BAK Documents\ and\ Settings DOCUME~1 ESJWT hiberfil.sys logCleaner.txt LOGCLE~1.TXT MSOCashe pagefile.sys PerfLogs Program\ Files ProgramData PROGRA~1 PROGRA~2 PROGRA~3 Python34 Recovery System\ Volume\ Information SYSTEM~1 win7.ld Windows

[Anon10]

When I first got my SSD, my OS was installed onto my 500GB hard drive. I used a migration tool by Samsung to put my OS onto my SSD. After having it like this for a few months my boyfriend thought it was better to have installed windows freshly onto my SSD so I did that. That was the last installation I did and it had been fine for ages until recently like I said in the first post. Does that explain why it is set up weirdly?

[Wonko the Sane]

Cannot say, that is the actual question, as normally a SSD is "treated" like a hard disk like device (mainly because it is a hard disk like device ) and as such it is partitioned, while yours evidently is not (but still worked fine).
 
Now the issue is the following.
Try issuing the command:
  

cat --hex (hd0)1+1

 
and check that you can see (on the right) the string "B.O.O.T.M.G.R." at the beginning, this would mean that the VBR is the "original" Windows 7 one and actually invokes BOOTMGR. (it may be possible that you see a different string, possibly "w.i.n.7..l.d")
 
It is very possible that what happened is that the grub4dos grldr has been renamed to BOOTMGR and that the BOOTMGR has been renamed to *something else*, as *somehow* when you boot you get to grub4dos, but it is as well possible that *some other* booting sequence is setup by the stupid loader, namely the file "win7.ld" might well be a grldr renamed.
 
A grub4dos grldr (particularly if an oldish version), should be around (or less than) 270 Kb, whilst the "normal" Windows 7 BOOTMGR is around 380 Kb.
Try issuing the commands (after having already set root to the SSD executing "root (hd0)":

blocklist /bootmgr

 
If the result is similar to:
(hd0)123456+750
it means that the bootmgr is the "right" file, sized around 380 Kb
and

blocklist /win7.ld

gives a result similar to:
(hd0)123456+525
it means that the win7.ld is a renamed grldr.
 
The result of a blocklist command is an address (start address of the file) separated by the extents of the file by a "+" (address and extent ae given in 512 bytes blocks), the above should happen if the files are contiguous, if they are in two (or more) segments (rare, but it may happen) you would get comma separated "sets of addresses" like:
(hd0)123456+380,  23456+145
what matters is the sum of the (bolded) extents.
If it is around 750 it is likely that the file is a "real" BOOTMGR, if it is around 525 it is likely that the file is a "grldr" (renamed).
 
IF you find that the "blocklist /bootmgr" returns around 750, then try issuing the commands:
 
 

chainloader /bootmgr
boot

 and report.

 

Wonko

[Anon10]

I can see in linux that the bootmgr file is 383.8kB and the win7.ld is only 20 bytes and just contains "eJxzDfYKDwEABIoBjg==". Do you still want me to check them through grub4dos? I will try the first command you gave soon

Edited by Anon10, 12 November 2014 - 07:50 PM.

[Wonko the Sane]

I can see in linux that the bootmgr file is 383.8kB and the win7.ld is only 20 bytes and just contains "eJxzDfYKDwEABIoBjg==". Do you still want me to check them through grub4dos? I will try the first command you gave soon

No need to check the size of the file, it seems "like it". 750*512=384,000 (which can well be the 383.8kB you found.

 

You should still look at the (hd0)1+1 (that is second absolute sector of the device or LBA1) to check which file is invoked by the bootsector, of course you can do the check with a disk editor from Linux instead of using grub4dos.

 

The "normal" booting sequence of a Windows 7 PC (with a "normal", partitioned hard disk) is:

BIOS->MBR->PBR->BOOTMGR->choices in \boot\BCD

 

in your case, since the device is not partitioned, *somehow* it must boot similar to:

BIOS->PBR->BOOTMGR->choices in \boot\BCD->Winload.exe->Windows 7

 

but right now it boots to grub4dos.

 

Grub4dos is normally booted in in two possible ways:

1) BIOS->MBR->grub4dos <- which cannot be the case

2) BIOS->MBR->PBR->grub4dos or BIOS->PBR->grub4dos

Or, instead, if the PBR calls BOOTMGR:

3) PBR->BOOTMGR->choice in \boot\BCD->grub4dos

or

4) PBR->BOOTMGR->choice in BOOT.INI->grub4dos <- rare, not common

 

So right now there are two possible cases:

a. the PBR does load BOOTMGR but the \boot\BCD (or BOOT.INI) only has one entry pointing to grub4dos

b. the PBR does NOT load BOOTMGR, but *somehow* loads directly or indirectly grub4dos 

 

If it is a. (which I doubt) we will need to check/fix the \boot\BCD, while if it is b. (as I believe/hope) chainloading the BOOTMGR should mmake you boot Windows 7 "normally", but still we need to understand how to fix "permanently" for the next booting.

 

Wonko

[Anon10]

B.O.O.T.M.G.R is on the first line when I run the command. How do I do the chainloader thing?

[Anon10]

I'm not sure if this is right but I tried:

root (hd0)
chainloader /bootmgr
boot

It seemed to do something but there was an error. In the error it says this:

File: \Boot\BCD
Status: 0xc0000225
Info: An error occurred while attempting to read the boot configuration data.

Is this a big problem?

[tinybit]

(hd0)/bootmgr , this reminds that your bios has made your usb mbr track hidden/invisible. too bad.

try this and see if it could go any further:

map (hd0) (fd0)
map --hook
chainloader (fd0)
root (fd0)
boot

[Anon10]

On chain loader (fd0) it says invalid or unsupported executable format. Also I thought fd0 was my USB stick so why would o try to boot that?

[Wonko the Sane]

Well, the good thing is that the bootmgr is seemingly a "right" BOOTMGR that has now issues with the \boot\BCD.

If what Tinybit suspects is what happened, try again, with these slightly modified commands:

map (hd0) (fd0)
map --hook
root (fd0)
chainloader (fd0)+1
boot

Wonko

[Anon10]

That gives me the same error as when I start up my computer before going to the command line.

[Anon10]

[Wonko the Sane]

OK.

So what it seems like is that right now when you boot you have (possibly) this sequence:

BIOS->PBR->BOOTMGR->\boot\BCD ONLY one choice in it for the grub4dos->grldr->grldr's menu.lst with that set of choices.

By re-mapping the (hd0) to (fd0) and chainloading the BOOTMGR you are going into this loop:

BIOS->PBR->BOOTMGR->\boot\BCD ONLY one choice in it for the grub4dos->grldr->grldr's menu.lst with that set of choices-> command line chainloader to BOOTMGR->\boot\BCD ONLY one choice in it for the grub4dos->grldr->grldr's menu.lst with that set of choices

 

The issue here is probably the sum of two things:

1. your unusual "unpartitioned" device 
2. the stupid loader not taking into account this eventuality and thus creating *somehow* the loop

 

It is still to be understood where exactly the grldr, and it's menu.lst are (the only possible explanation is that they are *somehow* in the file "ESJWT" that was listed with ls) but, more than that how exactly your windows booted before the loader was installed.

 

 

Try the following:

chainloader /ESWJT

If it displays something like "Will boot grldr from ..." then that is the file used in the booting process.

 

It is possible that before your PC booted through another disk/partition, i.e. the \boot\BCD on that SSD device has always been a not valid one .

 

Can you check on your other disks (through the Linux Live or through grub4dos ls) if on any of them (they will be (hd1,0), (hd1,1), (hd2,0) there is:

a "BOOTMGR" file in root of partition

a \boot\ folder and in it a \BCD file

?

 

That would be:

root (hdm,n)

ls

ls /boot

 

with the said m,n values.

 

Wonko

[Anon10]

I will try "chainloader /ESWJT". Could the files needed have possibly just been deleted by the loader?

I am pretty sure it booted from the SSD only because one of the hard drives is only a few weeks old and the other one was formatted and only has my personal files on it.

[Anon10]

ESJWT is 399.9kB and is a binary file. I can't open it with anything to see what is inside.

[Wonko the Sane]

ESJWT is 399.9kB and is a binary file. I can't open it with anything to see what is inside.

Sure , and you were not asked to attempt opening it.

 

You were asked to simply try chainloading it and report the grub4dos feedback.

 

Basically it could only be the "Will load ...." or a "Bad file type.... " error.

 

Usually there are reasons why *something* is suggested and *something else* is not.

 

But of course you can (say) run 

cat --hex /ESJWT

and check that it's first few bytes are EB3E80052039FFFF, which are AFAICR the grub4dos grldr initial bytes values.

 

Anyway, that is a "side curiosity", if you say that the thingy used to boot without the other hard disks, the "how the heck it did boot before?" question still remains.

 

Normally in situations like this the "usual" recovery is that of booting a PE (or a Windows 7 install DVD) and run a couple commands to "fix" the bootsector (and optionally the MBR) and  repair the \boot\BCD, but how these same commands will operate on your "strange" superfloppy situation is (at least to me) unknown, and it may do more damages than good.

 

I am very reluctant to try that way as it could be potentially "destructive".

 

In case of need do you have available?:

1. a Windows 7 install DVD or .iso
2. an "expendable" USB stick that we can use (i.e. that contains no important data, as they will be lost in the attempts)?

 

 

Wonko

[Wonko the Sane]

On second thought, this is "not enough" .

Now the issue is the following.
Try issuing the command:
  

cat --hex (hd0)1+1

 
and check that you can see (on the right) the string "B.O.O.T.M.G.R." at the beginning, this would mean that the VBR is the "original" Windows 7 one and actually invokes BOOTMGR. (it may be possible that you see a different string, possibly "w.i.n.7..l.d")
 

There is "another" loader name past the beginning of the second sector at  offset 0x5C.

 

Please try running again the :

cat --hex (hd0)1+1

Do you have N.T.L.D.R. at offset 0x5C or do you have something else, like "E.S.J.W.T." or "w.i.n.7..l.d" there?

 

Try also running the command:

cat --hex  /bootsect.bak

and check the same, it  is very likely that the file is actually a bootsector backup.

 

Are you using a Linux on CD/DVD or a on a bootable USB stick (i.e. can you boot to the Linux and run some commands to copy a few files from the hard disk and upload them for review)?

 

 

Wonko

 

 

[Anon10]

I understood that me checking the file in linux was not instead of the command, but every time I load linux I have to install programs again and I am in the process of sending a large file through FTP so I was reluctant to restart earlier. As soon as I am done sending I can restart and try the commands. I have a usb stick and disks I can put things onto if needed. I have an ISO for windows but as I got it from my boyfriend it might not be 'clean'. I don't know how else to get an ISO though. And yes I could put files onto disk or usb while I am in Linux.

Edited by Anon10, 15 November 2014 - 09:45 PM.

[Anon10]

I have an ISO for windows but as I got it from my boyfriend it might not be 'clean'.

I just realised how that might sound xD I meant it might not be the exact copy that you would get from Microsoft.

[Anon10]

I plugged in one of my usb sticks ready to use and it has windows 7 files on it already. Perhaps it was used in the past to install windows but this might help?

[Anon10]

I just looked through the files and realised it is full of non genuine stuff. Where can I get a non-tampered-with windows ISO that I can just use my key to activate? And if I fix windows and realise my install before was dodgey, could I make a backup onto another hard drive, reinstall windows on my SSD and then load the backup to make it all proper and genuine without losing all my programs and settings?