327 replies to this topic

[Dietmar]

Hi all,

 

after 14 hours  work

I succeed to build a generic XP SP3, updated with what I can get,

which runs on nearly every compi without any BIOS support for nvme.

 

It is absolut stable.

For to test this, I run defrag on nvme disk, prime95, 3Dmark, chkdsk on nvme disk,

firefox, youtube videos, connect USB stick.

 

For this to get, you need to be very careful with Tutorial 7.

The result is amazing.

 

In Tutorial 7 I changed in menu.lst

root (hd0,0) against rootnoverify (hd0,0)

Oh, this was the reason for soso many blue screens 10 years ago,

because error rootnotverify (hd0,0).

 

Xp SP3 with Tutorial 7 on Asus z87-pro (zero nvme in BIOS) motherboard, Samsung 960 pro nvme disk, Fat32 c

no other device connected.

-----------------------------------------------------------------------
CrystalDiskMark 5.1.2 © 2007-2016 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

   Sequential Read (Q= 32,T= 1) :  2658.701 MB/s
  Sequential Write (Q= 32,T= 1) :  1901.398 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   530.866 MB/s [129606.0 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   340.442 MB/s [ 83115.7 IOPS]
         Sequential Read (T= 1) :  2035.464 MB/s
        Sequential Write (T= 1) :  1802.148 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    58.420 MB/s [ 14262.7 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :   251.018 MB/s [ 61283.7 IOPS]

  Test : 1024 MiB [C: 44.5% (7.1/15.9 GiB)] (x5)  [Interval=5 sec]
  Date : 2018/07/29 0:52:25
    OS : Windows XP Professional SP3 [5.1 Build 2600] (x86)

 

This looks like magic

Dietmar
 

[Dietmar]

Hi all,

works also on MSi MS-7379 with Intel Core 2 Quad Q6600 from 2008.

I think, this is really first time XP nvme on this compi as boot device,

have a nice day

Dietmar

 

 

 

PS: An interesting thing I noticed during build of nvme XP:

       When I copy a file with 16 Gb and make a bit to bit comparisations check after

       on nvme disks needs 2 times to copy, to make it identic.

       The same behavior I noticed on USB sticks and

       compact flash discs.

 

Nvme disks do not like heat. Those problems I never had with harddisks.

 

 So think very careful, where you put important data!

[Wonko the Sane]

In Tutorial 7 I changed in menu.lst

root (hd0,0) against rootnoverify (hd0,0)

Oh, this was the reason for soso many blue screens 10 years ago,

because error rootnotverify (hd0,0).
 

Allow me to doubt that that can be the issue , or if this is confirmed, it is a "side effect" or collateral damage. 

 

The root and rootnoverify commands are essentially the same, the difference is only on the "underlying" (hd0,0), it is entirely possible that for *some* reasons the underlying image has some issues that trigger the behaviour.

 

This:

 

 

title Image chainloading USB (or nvme)
map --read-only /XP.IMG (hd0)
map --hook
rootnoverify (hd0,0)
chainloader +1

 

this:

 

 

title Image chainloading USB (or nvme)
map --read-only /XP.IMG (hd0)
map --hook
root (hd0,0)
chainloader +1

 

and this:

 

 

title Image chainloading USB (or nvme)
map --read-only /XP.IMG (hd0)
map --hook
root (hd0,0)
chainloader /ntldr

 

should be perfectly equivalent, and in a number of cases (has to be tested specifically of course) there is no need to establish a root at all, i.e. both:

 

title Image chainloading USB (or nvme)
map --read-only /XP.IMG (hd0)
map --hook
chainloader (hd0,0)0+1

 

and

 

title Image chainloading USB (or nvme)
map --read-only /XP.IMG (hd0)
map --hook
chainloader (hd0,0)/ntldr

 

might work just fine.

 

Wonko

[Dietmar]

Hi jaclaz,

I will test your last menu.lst

 

title Image chainloading USB (or nvme)
map --read-only /XP.IMG (hd0)
map --hook
chainloader (hd0,0)/ntldr

 

 

Hihi, a world full of missunderstanding:

The first blue screen happens because of

spelling mistake  rootnotverify from s4e,

have a nice day

Dietmar

[Dietmar]

Hi jaclaz,

 

title Image chainloading USB (or nvme)
map --read-only /XP.IMG (hd0)
map --hook
chainloader (hd0,0)/ntldr

 

works also and is faster than before .

 

Until now I think, the potential of the idea from s4e

is just not full understand:

His idea should work on really every device,

have a nice day

Dietmar

 

PS: Also nice would be a new, easier Tutorial for nvme boot.

[dencorso]

Hi, Dietmar!

Wonderful results! Keep on the great work!

Let me ask you a question: After the system is booted and running, if you try to add or remove things from the system hive, by using regedit, then reboot... do the modifications remain or not? Moreover, does the system allow the changes or does it bark "the file is read-only"?
 

Have a nice week!

[Dietmar]

Hi dencorso,

until now, you boot always up with the same hive "system", because it is "read only".

The other parts of the registry work normal.

As far as I understand, writes XP the changes in "system" from ram back to

Controlset001 at  shutdown and makes a copy of Controlset001 called CurrentControlset on next boot.

This can be done by a batch file also on shutdown, but then must the booted "system" from fakeCD has to be

on a writable medium. I think, it is not so difficult to reach this.

On Hive "system" changes in hardware are noted and the "last good configuration".

So, new hardware is only recogniced on working XP and gone on next reboot until now.

I installed some new programms on this XP, they all appear on next boot normal,

because they do not write to "system".

I found a funny limitation: I think to enlarge my Fat32c filesystem. This is possible,

but on next boot its gone. At the moment this is good, because it would change the mbr

and then the mbr checksum does not match any longer.

With some work, it may be possible, not to use the extra boot medium CD, after you installed in BIOS the

UEFI files for nvme. This works on every compi, but only for UEFI.

But this UEFI recognices the bootsector of the nvme disk. So, may be there can be a split

in 2 phases again, but only on nvme disk,

have a nice evening,

very hot here since a week always more than 30 degrees

Dietmar

 

PS: Until now no crash, compi z87-pro with XP from nvme was online whole day.

[Wonko the Sane]

As far as I understand, writes XP the changes in "system" from ram back to

Controlset001 at  shutdown and makes a copy of Controlset001 called CurrentControlset on next boot.

No. 

There are (normally) two hives in System:

ControlSet001

and

ControlSet002

 

The CurrentControlSet does not "exist" at all, it is a (sort of) reparse point, created on-the-fly when booting that points to either ControlSet001 or ControlSet002, depending on the contents of the  HKEY_LOCAL_MACHINE\SYSTEM\Select key.

 

When the system is booted, provided that (say) the chosen ContolSet is ControlSet001 there is NO difference whatever between ControlSet001 and CurrentControlSet as the latter is simply another name and access point for ControlSet001.

 

When the system is off, the SYSTEM backing file does not contain any CurrentControlSet hive, only ControlSet001 and ControlSet002.

 

Wonko

[Dietmar]

Hi all,

I just enlarge the nvme XP SP3 to 500 GB Fat32c.

It just boots fine, fast .

This means, on real XP SP3 no need for checksum of MBR,

because now it is just different as I prove with Winhex

Dietmar

 

EDIT:

Hm, but now stability of the nvme XP is gone,

so better make checksum of MBR identic .

[Dietmar]

Toshiba RD400 works also for nvme boot XP, stable.

Samsung 950 pro works only, if you succeed to copy bit by bit a working nvme XP on it and run chkdsk on it.

Without kicker CD this Samsung 950 pro does not work, unclear for me why not. It always shows "ntldr not found".

Legacy nvme Win7 works on Samsung 950 pro.

Interesting: The Toshiba RD400 needs only one write of 16 GB,

Winhex compare shows identic at once with copied file

Dietmar

[cdob]

until now, you boot always up with the same hive "system", because it is "read only".
The other parts of the registry work normal.
As far as I understand, writes XP the changes in "system" from ram back to
Controlset001 at  shutdown and makes a copy of Controlset001 called CurrentControlset on next boot.
This can be done by a batch file also on shutdown, but then must the booted "system" from fakeCD has to be
on a writable medium.

Do you use volume shadow copy?

At running XP:
mount the image, create a volume shadow and copy the system file, unmount the image


Example to clarify the idea, not tested
assumption: the image is mounted to f:

rem Volume Shadow Copy Simple Client
rem http://vscsc.sourceforge.net/
vscsc.exe -exec=clone_C2F.cmd %SystemDrive%

.
clone_C2F.cmd

@echo off
rem dosdev by Olof
dosdev.exe B: %1
dir b:\
copy B:\Windows\system32\system f:\Windows\system32\system
pause

.
In addition, online creating the whole image should be possible.
Imagine a added mass storage controller, e.g. a SCSI, USB, SD controller: *.sys files are copied to system32\drivers at installation. These '.sys files are to be copied too.

A raw example can be ImageCopyFilesXP.cmd http://reboot.pro/to...tor/#entry55556
This was about offline creating back then. Incldue vscsc.exe and change to online crating.
The file storport.sys is added to the image already. nvme.sys should be selected automatic.

[Dietmar]

Hi cdob,

thank you a lot for your idea!

 

The problem in "Kansas City Shuffle" is:

How to update the hive "system" always, like in normal XP. Until now hive system is read only on CD.

 

When I read the description of "volume shadow copy" I see,

that it is possible at any time to make a backup from any file from XP, even some programs make use of it.

But I do not understand in full, how the batch program can reach this.

 

I understand from your idea: You try to copy from the running "Kansas City Shuffle" the actual hive system

at a special timepoint back to the "CD", right?

 

Until now, the kicker CD is always mounted as G:\. (This can be in future also a writable USB stick, working as floppy B:\.)

Now comes the batch file:

 

vscsc.exe -exec=clone_C2F.cmd C:\

 

with clone_C2F.cmd

 

@echo off
dosdev.exe C: %1
dir c:\
copy C:\Windows\system32\system B:\Windows\system32\system
pause

 

When does this batchfile start? And can this been put together all in one batch file?

 

I think, you try to make this possible also before,

where was the problem,

 

have a nice evening

Dietmar

 

PS: I noticed, that it is not possible to extract the hive "system" as system.reg from the running "Kansas City Shuffle".

       It crashes and the builded system.reg file is empty.

Correction: It crashes only on Samsung 960 pro. On Toshiba RD400 and on Samsung 950 pro

it does not crash. But it is not possible, just to update System via system.reg file on next boot,

message comes: "Not all keys can be set."

[Dietmar]

Also with 3 nvme disks connected (Samsung 960 pro, 950 pro, Toshiba RD400)

the "Kansas City Shuffle" starts with the driver nvme.sys ver. 1.3 from Kai,

it is stable

Dietmar

[cdob]

Until now hive system is read only on CD.

What's a CD A 12 cm pice, to put a cup on top? Sorry, could not resist.
What about change to a writable media? Another internal driver or a USB stick?
 

When I read the description of "volume shadow copy"

"volume shadow copy" is a default XP service, vscsc.exe uses the existing XP service.
It freezes the hard disk time, travels at light speed to spacetime and creates a parallel universe
There are two virtual volumes after, a old historic one at one universe.
And another virtual virtual volume with current files at the other universe.

A whole running XP can be cloned that way, even at open files.
Another Olof program:
strarc.exe -c -j -d:B:\ | strarc.exe -xd:F:\
 

I understand from your idea: You try to copy from the running "Kansas City Shuffle" the actual hive system
at a special timepoint back to the "CD", right?
 
Until now, the kicker CD is always mounted as G:\. (This can be in future also a writable USB stick, working as floppy B:\.)

Yes, write to the USB stick.

The two lines translated:
vscsc.exe -exec=clone_C2F.cmd %SystemDrive%
dosdev.exe B: %1

vscsc.exe creates a volume shadow ID from %SystemDrive%, often the volume C:
dosdev.exe maps the volume shadow ID to the letter B:
B: is the old volume c: at the parallel historic universe.
C: is the current c: at the current universe.

[Dietmar]

Hi cdob,

when I change the CD against a writable USB stick,

"Kansas City Shuffle" is not rock stable anymore.

The kicker USB floppy has no device letter on starting XP.

When it gets one, it crashes.

So, may be exact this USB stick has do be in the exact USB slot,

when you build the kicker image.

You work quite long time with "Kansas City Shuffle".

So I wonder, what kind of experience you have

Dietmar

[dencorso]

So, may be exact this USB stick has do be in the exact USB slot,

Yes, one has to use the exact same USB connector always, unless one changes the CriticalDeviceDatabase, as per your classic Tutorial 2! karyonix (    ) pointed that to me a long time ago: please read the two last posts of this old thread.

[Dietmar]

Hi dencorso,

thanks a lot, it is so funny with nvme boot:

When you disconnect the USB stick, before it gets a letter,

all is ok. Yes, this USB stick loses contact with USB files from Bios, when starting level 2 of bootstage.

But it is not asked for that, because the nvme disc rules with nvme.sys driver from the USB stick in last second of its "life".

Oh, when bootstage2 is ready, suddently there are USB drivers again

and for the USB stick it looks like new life again, means possibility to crash nvme disk

Dietmar

[Dietmar]

Hi all,

fun goes on! I just copy bit by bit the XP.IMG to the usb stick. Not usb friendly, no grub4dos .

This I connect to the compi with the nvme disk, BIOS has no idea about nvme.

Oh, so much fun: The start usb stick is gone

during boot, when it losts contakz with the usb files from bios.

XP starts from the files nvme.sys and storpor.sys which fresh brought by usb stick before dying.

Then at full XP message comes, that usb stick is found .

Now they live in peacefull coexistence, usb stick shown as removable device.

This gives the big advantage, that now using shadow copy I do not need to mount the image,

it is open all the time on usb stick

Dietmar

 

EDIT: I delete the key

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

on the usbstick before first boot. In other case it crashes on 2. boot.

This is very funny. XP seems to make a copy of the loaded hive system as its own file system,

because there the key HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices is also gone.

May be, XP does not need this files from usbstick for to have as its own. I will test.

[Wonko the Sane]

This I connect to the compi with the nvme disk, BIOS has no idea about nvme.

Oh, so much fun: The start usb stick is gone

during boot, when it losts contakz with the usb files from bios.

XP starts from the files nvme.sys and storpor.sys which fresh brought by usb stick before dying.

Then at full XP message comes, that usb stick is found .

Now they live in peacefull coexistence, usb stick shown as removable device.

That would be a "loop" Kansas City Shuffle.

In the original the initial image is only used for the first part of booting, and later NOT mounted (but it could be using - say - IMDISK, FIRADISK or similar).

In this version the automatic auto-detection of USB devices kicks in and re-mounts (as a secondary, not boot device) the USB stick.

 

The MountedDevices key needs to be deleted because of this second mounting, though actually only the specific two keys related to the volume on the USB stick could be deleted.

 

I would also try to unmount/unassign the drive letter (Mountvol or similar) of the USB stick before rebooting, maybe that would be enough to have a clean 2nd boot. 

 

Wonko 

[Dietmar]

Hi jaclaz,

thanks for help!

I renamed hive system on nvme disk, compi reboots.

I make an empty system hive system on nvme disk, reboot.

So, the hive system is necessary for booting nvme from kickstarter, even hive system is loaded from kickstarter to ram.

Even I use FAT 32, the compi corrected the clock in hive system on the usb stick (this means writing there)

Dietmar

 

EDIT: NO writing to hive system on USB stick after deleting HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices on USB stick before 1. boot. This is very important!!! I just load both hive system before and after, export them to before.reg and after.reg and compare with "Beyond Compare 2". This is a very good news, because now Shadow Copy can happen, makes sense. Very clear situation now, nice.

 

EDIT2: Hm, even the registry entries for system are identic, a direct compare of hive system on usb stick before load and hive system after loading shows a difference! Now I understand, why booting from CD gives a rocksolid XP but from USB stick not. There are more entries in registry possible, than export as *.reg can show.

This is bad for Shadow Copy", because the usb stick must be writable for this.

[Dietmar]

Hi all,

I write about 100 times 16 Gbyte to the Samsung 960 pro.

Oha, now on nearly every boot comes error messages about disrupted sectors.

Here it is very hot, today nearly 40 degrees. The Samsung stick reaches temperatures like for cooking. 

 

I think, I like normal harddisks more

Dietmar

 

PS: Also the Sandisk ultra USB stick: Write file about 150 MByte, nearly always controll with Winhex tells,

      that some bytes are different. I understand, why Microsoft certified only very few USB sticks.

      I have one from Kingston DT Workspace, there do this bad things not happen.

[Wonko the Sane]

PS: Also the Sandisk ultra USB stick: Write file about 150 MByte, nearly always controll with Winhex tells,

      that some bytes are different. I understand, why Microsoft certified only very few USB sticks.

      I have one from Kingston DT Workspace, there do this bad things not happen.

Hmmm.

 

It depends on a number of factors, but if the different bytes belong to unallocated space, then it is likely the wear leveling algorithm switching sectors.

 

If that was not the case, you would have corrupted files very, very often, and that would make the stick totally unusable in practice.

 

Wonko

[Dietmar]

Hi jaclaz,

the funny thing is,

that in most cases, when you rewrite the USB stick with the same file again,

after this rewrite it is identic.

I think, it is really a big problem of most sticks and only the repair

operations on this sticks do not show big damage at once.

At school I installed USB Windows on USB sticks, all with the Hitachi filter and EWF enabled.

After one week, all sticks do not funktion correct any longer, show crazy behavior, real destroyed,

even it is only read from them!

Only the Kingston DT stick was still alive.

So I changed the USB sticks against USB harddrives.

Without any problems, all with the Hitachi filter and EWF enabled, they work there now for 3 years

Dietmar

 

EDIT: The Toshiba RD400 500GB nvme was brandnew. Writing 16 GB lasts in the beginning about 2 min,

depends on black WD 2TB, writes max 200 MByte/sec. After may be 10 times doing this,

suddently the time reaches 5 min and now 10 min. This means, it is much slower than the harddisk in writing

a continues file of 16 GB! The funny thing for the Toshiba is, that this file is always to 100% correct.

EDIT: The Toshiba SSD tool tells me, that my RD400 is 100% healthy, no media error.

I just format it with this tool. Hm, strange. During write of 16 GB direct to the media via Winhex, format type is unimportant?!..I see, that something changed on the RD400. The tool gives zero answer for this.

Update: Oh, this is really funny: After "format" with the Toshiba SSD tool, the RD400 shows only 00 on it.

I just copy the 16 GB continues file on it: Waooh, now it needs only 79 sec, meaning the format tool is doing much

more with this disk, but I dont know what.

 

The Samsung 960 pro is still as fast as in the beginning. In 1 from 3 times 16 GB file now there are errors on it.

I use with Win10 the Magician software. This one told: 2 TB are written, the disk is good.

When you take a deeper look on the 960 pro you see, that the intern controllers told errors in more than 1000 cases.

 

https://www.searchst...-Spruenge-hilft

 

I do not think, that you need this for harddisks!

 

 

Does somebody know a tool, with which you can read parameters of any nvme disk?

[Dietmar]

With the "new" RD400 the "Kansas City Shuffle"

is now rocksolid as before and very fast.

But it does not like, when the kickstarter on USB stick gets mounted.

I think, because XP does not know, how to handle 2 devices with the same signatur

 

Dietmar

 

PS: When you start with the kickstarter USB stick, looking like real harddisk without grub4dos,

you have to disconnect it, before it is again recogniced.

Because of this, when you connect new hardware, you have to copy by hand the hive system from

RD400 to USB stick. This works.

[dencorso]

Hi, Dietmar!
What about using a RAM mapped kickstarter? I mean:

title Image on RAM chainloading USB (or nvme)
map --mem /XP.IMG (hd1)
map --hook
chainloader (hd1,0)/ntldr

And the host pendrive can have an MBR with a different checksum and signature, so that XP won't hate it.

BTW, I have a Kingston DT Workspace 64G and a Super*Talent RAIDDisk 32G (which I bought used... it's out of the market for a long time, now). They're the fastest and most reliable pendirves I've ever had (and also may be used to fry eggs!). It's too bad Wonko doesn't even consider them pendrives...  
 

Have a nice day!