The bcdedit.exe tool has lots of parameters and many of them are well documented.
One parameter that I have not seen described anywhere, except on 1 line in the documentation, is STAMPDISK.
It is supposed to sign raw disk when booting winpe.
I have not been able to set this one to any bcd entry yet.
By stringdumping the newer version of bcdedit.exe, I suspect the right usage should be STAMPDISKS and not STAMPDISK.
Have anybody been able to load raw disk images to ram and boot from it, using the new OS? All my tests end with the famous ...7B.
Does anybody know how this STAMPDISKS/STAMPDISK correlates and works with the device specific options about ramdisk?
Btw, I also tried booting winpe(7) with a nested vhd inside a rawdisk mapped to ram with grub4dos. It crashed with 7B halfway into the bootprocess (not very surprising though). The interesting part here is that the booting started and executed winload.exe from such a nested vhd-setup.
Joakim
bcdedit - stampdisk (parameter)
Started by
joakim
, Jul 02 2009 01:28 PM
18 replies to this topic
#2
was_jaclaz
-
- Advanced user
-
- 7101 posts
Finder
- Location:Gone in the mist
-
Italy
Posted 02 July 2009 - 03:02 PM
The only references I could find was for STAMPDISK (without the S).
http://download.micr...Dedit_reff.docx
It apparently allows "stamping" a disk signature on a RAW device (i.e. and unpartitioned one) but I am completely failing to understand what would be a practical use of it.
jaclaz
http://download.micr...Dedit_reff.docx
http://www.ads-train...CDedit_reff.docSTAMPDISK Boolean Enables stamping of RAW disks during a WinPE boot.
Available only on Windows Server 2008 Beta 3 and later.
It apparently allows "stamping" a disk signature on a RAW device (i.e. and unpartitioned one) but I am completely failing to understand what would be a practical use of it.
jaclaz
#3
joakim
-
- Team Reboot
-
- 912 posts
Silver Member
- Location:Bergen
-
Norway
Posted 02 July 2009 - 03:30 PM
That is the doc I was referring to, and the only place I have ever seen it mentioned, except inside bcdedit.exe itself.
I am sure it is there for a reason, and since it clearly is for winpe usage, I would be interested to know what excactly for...
Joakim
I am sure it is there for a reason, and since it clearly is for winpe usage, I would be interested to know what excactly for...
Joakim
#4
was_jaclaz
-
- Advanced user
-
- 7101 posts
Finder
- Location:Gone in the mist
-
Italy
Posted 02 July 2009 - 03:45 PM
I am sure it is there for a reason, and since it clearly is for winpe usage, I would be interested to know what excactly for...
Yep.
But my question was, if I may insist, a bit more subtle
:Let's assume that this, as per (very scarce) docs, allows the BOOTMGR to write a disk signature on a RAW disk, WHAT would "writing a disk signature on a RAW disk" be useful for?
jaclaz
#5
joakim
-
- Team Reboot
-
- 912 posts
Silver Member
- Location:Bergen
-
Norway
Posted 02 July 2009 - 04:10 PM
Let's assume that this, as per (very scarce) docs, allows the BOOTMGR to write a disk signature on a RAW disk, WHAT would "writing a disk signature on a RAW disk" be useful for?
Exactly.
If RAW means unpartitioned and unformatted disks, it makes no sense as bootmgr cannot partition anyway, and the tools available later when winpe has fully booted, will do the signing if necessary. Ie, I guess it's meant to have a purpose in the early bootprocess. My initial guess was ramdisk usage, but not sure. It also states which OS's that makes use of it... And by coincidence, that is those capable of native boot vhd (if beta 3 is mostly the same as R2).
Any guesses?
Joakim
#6
was_jaclaz
-
- Advanced user
-
- 7101 posts
Finder
- Location:Gone in the mist
-
Italy
Posted 02 July 2009 - 04:18 PM
Yes, the only other "reference" if anything in a PowerPoint file can be defined such is here:
http://209.85.129.13...G...mpdisk&cd=3
http://download.micr...CPA051_WH06.ppt
I guess that RAW in this context means any disk that has not MBR "magic bytes" signature 55AA and partition table values.
I really cannot imagine an use for a disk signature on an "empty" disk (since BOOTMGR in itself cannot partition/format it.
jaclaz
is here:http://209.85.129.13...G...mpdisk&cd=3
http://download.micr...CPA051_WH06.ppt
Deployment Guidelines
Identifying disks
Windows Boot Environment uses disk signatures to identify partitions on disks
Avoids ambiguity of firmware enumeration dependencies
Always ensure a unique disk signature is present on disks
A special consideration to make for disk duplication
Special cases
Special designation for the boot partition
For un-partitioned disks, boot loader will not stamp disk signature
User must partition disk
A reboot may be necessary
I guess that RAW in this context means any disk that has not MBR "magic bytes" signature 55AA and partition table values.
I really cannot imagine an use for a disk signature on an "empty" disk (since BOOTMGR in itself cannot partition/format it.
jaclaz
#7
joakim
-
- Team Reboot
-
- 912 posts
Silver Member
- Location:Bergen
-
Norway
Posted 02 July 2009 - 04:40 PM
I guess that RAW in this context means any disk that has not MBR "magic bytes" signature 55AA and partition table values.
What I think it refers to, is the 4 bytes at offset 440 in mbr.
But that does not solve anything.
And it makes no sense to have bootmgr write a signature as part of a repair/recovery process either, as the more advanced tools will become available when winpe is booted.
Joakim
#8
was_jaclaz
-
- Advanced user
-
- 7101 posts
Finder
- Location:Gone in the mist
-
Italy
Posted 02 July 2009 - 05:27 PM
Yep, that's the disk signature, apart from NT based systems, which, if a disk signature is not present do force one when mounting the disk, all other operating systems do not use it.What I think it refers to, is the 4 bytes at offset 440 in mbr.
The only occasion when something like this would be useful would be to force a disk signature on a disk that is already partitioned/formatted under another OS, say DOS or Linux and has 00 00 00 00 as signature.
But such a disk is not actually RAW as the reference seems to hint.
Unless it means with an unknown filesystem, say for example reiserFS or Ext2/Ext3FS for which there is not a filesystem driver in the early part of booting.
In which case it would be a way to "tag" a disk even if it's parititoning/formatting is UNKNOWN (but which cannot be defined "RAW").
jaclaz
#9
joakim
-
- Team Reboot
-
- 912 posts
Silver Member
- Location:Bergen
-
Norway
Posted 02 July 2009 - 05:37 PM
And if so is its function, it does by definition not make any sense, as it is to be set on winpe entries in the bcd (which of course is not nix based anyway and does not have drivers for such filesystem).
This is annoying!
This is annoying!
#10
karyonix
-
- Advanced user
-
- 481 posts
Frequent Member
-
Thailand
Posted 03 July 2009 - 04:02 PM
Maybe useful for Windows Installation.
Boot loader can read drive 0x80's signature, drive 0x81's signature, ...
Windows can use signatures to identify which drive is 0x80, which drive is 0x81, ...
Windows Setup will install boot manager to drive 0x80 to make it bootable.
If you have two RAW harddisks without signature and boot Windows Setup from DVD.
Windows can see two drive but don't know which one is 0x80. Setup may guess wrong and install boot manager to second harddrive which BIOS will not load at startup.
Boot loader can read drive 0x80's signature, drive 0x81's signature, ...
Windows can use signatures to identify which drive is 0x80, which drive is 0x81, ...
Windows Setup will install boot manager to drive 0x80 to make it bootable.
If you have two RAW harddisks without signature and boot Windows Setup from DVD.
Windows can see two drive but don't know which one is 0x80. Setup may guess wrong and install boot manager to second harddrive which BIOS will not load at startup.
#11
was_jaclaz
-
- Advanced user
-
- 7101 posts
Finder
- Location:Gone in the mist
-
Italy
Posted 03 July 2009 - 04:31 PM
Maybe useful for Windows Installation.
...
Very interesting.
Though IF Windows setup cannot understand which drive is 0x80, I wonder how would BOOTMGR understand it, or, if the "understanding" is inside BOOTMGR, why there should be a provision for turning it ON (assuming that the default boolean value for STAMPDISK is 0).
I mean, if the good MS guys made (apparently) Vista WITHOUT this provision, got some bug reports, decided to fix this rare issue (two RAW disks connected at setup) and thus introduced the STAMPDISK feature in Server 2008, why they did it introduce in such a way (and nearly undocumented) that the value needs to be set?
In other words, if this is something that is necessary (even in a very small number of cases) what would have been the consequence of setting it at 1 by default?
jaclaz
#12
joakim
-
- Team Reboot
-
- 912 posts
Silver Member
- Location:Bergen
-
Norway
Posted 03 July 2009 - 08:43 PM
Well, the windows 7 RC1 iso haven't got it enabled by default.
If it's there because of possible conflicts when several RAW disks are present, I don't understand why vista and standard 2008 cannot make use of this feature. Then the newer OS has bugs that the previous did not have, and I find it less likely to be the case. I'm thinking there have to be some more advanced winpe booting stuff, possibly related to vhd or ramdisks.
Having this feature available and not present by default, leads me to think that it has absolutely NO usage from the product cd as it can only then be set to an existing BCD store after the OS is installed. That means diskpart would already have done the job of signing the disks and it makes no sense to add it to an entry in the freshly installed BCD store if missing signatures on RAW where the problem to be solved. The 0x80/0x81 issue would already be solved before you could set the entry. The only way to set this from the product cd is by dropping to PE-mode with SHIFT+F10 and entering cmd and then bcdedit (ie, setting the BCD store before any OS is installed, which makes no sense to me).
I can confirm that the documentation/reference is wrong and the correct parameter is STAMPDISKS.
Joakim
If it's there because of possible conflicts when several RAW disks are present, I don't understand why vista and standard 2008 cannot make use of this feature. Then the newer OS has bugs that the previous did not have, and I find it less likely to be the case. I'm thinking there have to be some more advanced winpe booting stuff, possibly related to vhd or ramdisks.
Having this feature available and not present by default, leads me to think that it has absolutely NO usage from the product cd as it can only then be set to an existing BCD store after the OS is installed. That means diskpart would already have done the job of signing the disks and it makes no sense to add it to an entry in the freshly installed BCD store if missing signatures on RAW where the problem to be solved. The 0x80/0x81 issue would already be solved before you could set the entry. The only way to set this from the product cd is by dropping to PE-mode with SHIFT+F10 and entering cmd and then bcdedit (ie, setting the BCD store before any OS is installed, which makes no sense to me).
I can confirm that the documentation/reference is wrong and the correct parameter is STAMPDISKS.
Joakim
#13
RulerOf
-
- Members
-
- 13 posts
Newbie
-
United States
Posted 27 July 2011 - 03:44 PM
First, let me apologize for resurrecting a 3 year old thread 
I'm reading the Windows Internals 5th Edition (Vista and Server 2008) and came across this entry in the chapter covering the BCD (specifically, page 1084). The purpose of the STAMPDISKS BCD element is as follows, according to the book (emphasis mine):
If I'm reading that correctly, I would venture to say that the whole point here is to assist WinPE in the process of resolving ARC paths for hard disk objects. The infamous "Windows cannot be installed to this disk" because it might not be bootable error that you can sometimes receive during Windows Setup occurs when Windows can't determine a valid ARC path for the device. See my odyssey where I figured out and worked around that issue on the Technet forums.
The ONLY time I've ever seen this issue is when attempting to install to an iSCSI target via the MS Software Initiator, or when booting WinPE from an iSCSI target. The root of the cause, though, has something to do with BIOS INT 13 drive [re]mapping, and of course, it varies from BIOS to BIOS. I really, really wonder if this BCD switch would help alleviate this issue for some people.
If I ever investigate it, I'll come back and let you know
Also guys, thanks for all the hard work you do here. These threads are often very, very informative!
Cheers,
RulerOf
I'm reading the Windows Internals 5th Edition (Vista and Server 2008) and came across this entry in the chapter covering the BCD (specifically, page 1084). The purpose of the STAMPDISKS BCD element is as follows, according to the book (emphasis mine):
Specifies that Winload will write an MBR disk signature to a RAW disk when booting WinPE. This can be required in deployment environments in order to create a mapping from operating system-enumerated hard disks to BIOS-enumerated hard disks to know which disk should be the system disk.
If I'm reading that correctly, I would venture to say that the whole point here is to assist WinPE in the process of resolving ARC paths for hard disk objects. The infamous "Windows cannot be installed to this disk" because it might not be bootable error that you can sometimes receive during Windows Setup occurs when Windows can't determine a valid ARC path for the device. See my odyssey where I figured out and worked around that issue on the Technet forums.
The ONLY time I've ever seen this issue is when attempting to install to an iSCSI target via the MS Software Initiator, or when booting WinPE from an iSCSI target. The root of the cause, though, has something to do with BIOS INT 13 drive [re]mapping, and of course, it varies from BIOS to BIOS. I really, really wonder if this BCD switch would help alleviate this issue for some people.
If I ever investigate it, I'll come back and let you know
Also guys, thanks for all the hard work you do here. These threads are often very, very informative!Cheers,
RulerOf
#14
joakim
-
- Team Reboot
-
- 912 posts
Silver Member
- Location:Bergen
-
Norway
Posted 27 July 2011 - 04:14 PM
Interesting post at technet I must say.
It is still a little unclear exactly what STAMPDISKS actually do. I found by RE and debugging that I could not prevent Windows from writing a disk signature when it's missing. I really tried many things on winload.exe without luck. The actual signature writing is happening regardless of the STAMPDISKS configuration in BCD.
It is still a little unclear exactly what STAMPDISKS actually do. I found by RE and debugging that I could not prevent Windows from writing a disk signature when it's missing. I really tried many things on winload.exe without luck. The actual signature writing is happening regardless of the STAMPDISKS configuration in BCD.
#15
Wonko the Sane
-
- Advanced user
-
- 16066 posts
The Finder
- Location:The Outside of the Asylum (gate is closed)
-
Italy
Posted 27 July 2011 - 04:31 PM
Hmmm....The actual signature writing is happening regardless of the STAMPDISKS configuration in BCD.
Maybe the difference is WHEN the signature is written (i.e. if the signature is written by BOOTMGR even before Winload.exe is called/executed).
And does it make a difference if STAMPDISKS is ON/OFF if you chainload "something else" (like a NTLDR or a grldr.mbr)?
Wonko
#16
RulerOf
-
- Members
-
- 13 posts
Newbie
-
United States
Posted 27 July 2011 - 04:37 PM
Good question Wonko. I might suggest booting with the parameter disabled, then enabled, on a system that's simply missing Winload altogether. Then see what happens, perhaps?
Edit: Got a little ahead of myself there. It says here that STAMPDISKS is explicitly targeted at Winload, and not at BOOTMGR. So my hypothetical situation above should yield identical results.
Edit: Got a little ahead of myself there. It says here that STAMPDISKS is explicitly targeted at Winload, and not at BOOTMGR. So my hypothetical situation above should yield identical results.
Edited by RulerOf, 27 July 2011 - 04:39 PM.
#17
joakim
-
- Team Reboot
-
- 912 posts
Silver Member
- Location:Bergen
-
Norway
Posted 27 July 2011 - 05:06 PM
The actual writing of the signature definetely not by bootmgr. It happens while winload.exe transfer execution onto the kernel, so I am more of the impression that the kernel takes care of this..
#18
Wonko the Sane
-
- Advanced user
-
- 16066 posts
The Finder
- Location:The Outside of the Asylum (gate is closed)
-
Italy
Posted 27 July 2011 - 06:28 PM
This would be logical, and more or less "parallel" to the way 2K/XP "switch" (compare with the XP Kansas City Shuffle).The actual writing of the signature definetely not by bootmgr. It happens while winload.exe transfer execution onto the kernel, so I am more of the impression that the kernel takes care of this..
But if it is the same mechanism, a disk with a 00000000 signature would work just as well (as the checksum would match anyway), so we are back to the idea that it is a very rare case, and probably triggered only "if and when" TWO disks, BOTH with a 00000000 signature are present? Again only thinking out loud...
(at least this behaviour would be consistent with your finding that the switch is "normally" irrelevant )
Wonko
#19
joakim
-
- Team Reboot
-
- 912 posts
Silver Member
- Location:Bergen
-
Norway
Posted 28 July 2011 - 08:21 PM
Just want to add a note about a test I just did. Flat booted winpe3 from hdd. Added and extra disk, so 2 disks are present. Now erasing the signature (00000000) on both will result in winpe booting fine and making sure "something" has written a different signature to both disks. Now making the signature on both disks set valid but identical, will result in winpe booting just fine without complaints, but without anything touching the signatures (both still identical). The stampdisks parameter was not configured on when booting.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
