10 replies to this topic

[joakim]

I just discovered that it is possible to set ScratchSpace to 1024.

The dism.exe tool will not let you do that, so you have to set it manually in registry. Just put 400 into the WinPECacheThreshold key.

I had to try 800 (2048) too, but that was not accepted and defaulted to the minimum size. I also tried on Server 2008, but that did not work.

So it appears to only be possible on Win7PE, at least RC1.



Joakim

[was_jaclaz]

Very interesting.

I guess that expecially for people not knowing what Scratch Space is (and whatever it is, it is NOT a ramdisk), and thanks to you carefully failing to detail how you changed it in the Registry, it will be very useful.

Just in case:
http://en.wikipedia....i/Scratch_space

http://technet.micro...e3.aspx?pr=blog

Scratch Space
A problem often faced by applications running under Windows PE is that many Windows applications (and even many components of Windows itself) expect to be run on writable storage. Many react in unpleasant ways when running from read-only media, such as a CD-R. For example, when I first tried getting Microsoft Internet Explorer® to run under Windows PE (and eventually when I tried just the MSHTA, or Microsoft HTML Application, components of Windows), key DLLs would not register because they required writable storage for some of the tasks they needed to complete as part of the registration process.
In Windows PE 2.0, this is not a problem since there is now up to 32MB of scratch space available for file system writes. As a result, components that previously didn't work due to the read-only nature of Windows PE will now work since they can perform the writes to disk that they require. This is different from a RAMDrive for scratch space (as has routinely been utilized by Windows PE users) in that the scratch space is on the same volume as the boot volume—as opposed to being another temporary drive.

http://technet.micro...261(WS.10).aspx

/Set-ScratchSpace:<size_of_ScratchSpace>
Sets the available scratch space, in megabytes. Valid values are 32, 64, 128, 256 and 512.

Example:
Dism /image:C:\test\offline /set-ScratchSpace:128

(yes 1024 is undocumented)

[url="http://www.deployvis...bid/70/EntryID/

[joakim]

It was mainly targeted to the Win7PE developers, so they can have it as an option in their script. I was just assuming they already knew where the key is located.

And for those that don't know what this is about. It is the size of the ramdisk (X:\)

The SYSTEM hive must be mounted and the location of the key with relevant value is:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\FBWF]

"WinPECacheThreshold"=dword:00000400

Joakim

[joakim]

It also works on 2008 Server PE, and possibly also vista.

Stupid me had patched the wrong index in the wim on the first test.

Joakim

[was_jaclaz]

OK .

But, for NON-Win7PE developers, is it a RAM disk or NOT?

The referenced article says it is NOT.

http://technet.micro...e3.aspx?pr=blog

Scratch Space
A problem often faced by applications running under Windows PE is that many Windows applications (and even many components of Windows itself) expect to be run on writable storage. Many react in unpleasant ways when running from read-only media, such as a CD-R. For example, when I first tried getting Microsoft Internet Explorer® to run under Windows PE (and eventually when I tried just the MSHTA, or Microsoft HTML Application, components of Windows), key DLLs would not register because they required writable storage for some of the tasks they needed to complete as part of the registration process.
In Windows PE 2.0, this is not a problem since there is now up to 32MB of scratch space available for file system writes. As a result, components that previously didn't work due to the read-only nature of Windows PE will now work since they can perform the writes to disk that they require. This is different from a RAMDrive for scratch space (as has routinely been utilized by Windows PE users) in that the scratch space is on the same volume as the boot volume—as opposed to being another temporary drive.

Since it is not the first time that the good guys at MS write something that is either inaccurate, otherwise undocumented, deceiving or simply plainly WRONG , I would appreciate understanding the actual nature of this ScratchSpace.



jaclaz

[joakim]

Every disk reading tool see it as \Device\RamDisk and it is in fact a disk created in ram (3 Mb partition image on which a wim is mounted). It therefore has some restrictions, among them the ability to create junction points.

Btw, it also works on Vista.

Joakim

[ludovici]

Hello Joakim

What is your WAIK ? The last WAIK (The Windows® Automated Installation Kit (AIK) for Windows® 7)?
Can you give me you WAIK web link ?
Thanks,

[joakim]

What is your WAIK ? The last WAIK (The Windows® Automated Installation Kit (AIK) for Windows® 7)?
Can you give me you WAIK web link ?

I used the the one for Windows 7 Beta from December last year. But that was just for mounting/unmounting the wims inside a virtual machine. The 3 different iso's tested (vista72008/win7) where all standard recovery cd without any tweaks (except this one entry for WinPECacheThreshold).

Joakim

[joakim]

Setting the undocumented value also works on nt5 based systems prepared with the wimboot script. I just applied it to moa (bartpe based on 2003 sources), which resulted in an iso at 128 Mb and writable freespace on X:\ at 1 Gb.

Joakim

[Lancelot]

Setting the undocumented value also works on nt5 based systems prepared with the wimboot script.

Hi Joakim,

I made some tests with LiveXP wimboot by using xpsp2 source.

when 1024 value used, it shows 1GB available on X:\ BUT it is not usable.
on my copy tests after ~470MB i can not copy anything more to X:\

Also tested with 512 value, X:\ shows 512MB available and copy test again shows the same upper limit ~470MB

Conclusion1: I dont know how it works with Win7Pe or VistaPE, but at least for LiveXP with xpsp2 source using 1024 value does not make sense.

ps1: maximum amount of size limit may slightly change due to the number of used files/folders.
ps2: ~470MB value is the total size of some files on a virtual disk
ps3: during tests compression option enabled on wimpack script

Further,
I also noticed something more, when using 1024 and 512 values, If X:\ reachs its maximum capacity, X:\ is not accessable anymore.
no such an issue if 256 and/or less used.

Conclusion2: 512 value should be used by advanced users who is aware that LiveXP may fail after max capacity.

reminding: I didnt test with xpsp3 or 2k3 sources.

[joakim]

when 1024 value used, it shows 1GB available on X:\ BUT it is not usable.
on my copy tests after ~470MB i can not copy anything more to X:\

I can verify the same issue on 2003 sp2 sources. It leads me to think we might have to modify the associated driver files to overcome this issue. Currently I'm reversing ntldr/setupldr.bin, so I don't know when to get time for this..

Joakim