Stimpy

Thanks for the info McRip. I'm sorry that you have had all this trouble. I hope the little script kiddy thats been doing this f****s off and dies.

I have found the same. Just nothing on it. Komm is still updating his utility, but I don't know where it gets the files from, as I've never used it. I would say get rid of it... As a side note, I don't see either Komm or McRip doing this much longer. Both of them ran out of patience with various issues and certain types of users many, many months ago. I feel a Solor coming on... Shame for some of us grateful users who depend on their expertise.

Hi Compstuff, I have never used the Toolkit for this before, and would love to know where you get the changelog.txt from, as I cannot see it in the list offered?

Hi Lego, I'm sure you have heard that McRip only lets your Toolkit and one other program access his server from now on, which is a damn shame, but understandable from his perspective. My question is that now this change has happened, will you be updating the Toolkit to access more of his server, than just the main folder, and the additions folder? It would also be good to be able to access the changelog.txt as well now. EDIT... OK, having never used this feature of the Toolkit before, I noticed that the rest of the folders are listed under Additionals (optional). Is this every folder that was available on the server? I just seem to remember from ages ago users here asking for more folders to be present in this function of the Toolkit, and I cannot remember if all folders were added or not...

Ahh I see, Well I use an SSD, and have always under-partitioned it, so to have better performance. And I can tell you that I still get the error during Windows setup.

Pretty sure that this type of USB stick cannot be partitioned... But would love to know if anyone has success with this.

It's a good question. I also own the same drive, and have the same issue with it. I have a feeling that the controller in the stick is slow at initializing, and is simply not fast enough for Windows Setup. If you watch the USB stick when Windows is setting up, you can see that it's being initialized, (just before setup asks what drive you want to install Windows on) as my mouse and keyboard also disconnect and reconnect at the same time.

Windows setup will run a refresh on the USB bus at the point that you are having problems with. One way to get around it, is to pull the USB disk out, then put it back in, and go back one step of Windows setup, and try again. This works in most cases with this error.

Because just how many programs can actually use 20GB/s of a RAM Drive? Nothing that WinToolkit does can even begin to approach those kind of speeds. Most WinToolkit's operations are running at speeds less than 20MB/s. The only operations that actually use a relatively high amount of bandwidth is the ISO creation, image building, mounting and saving tasks. I'm doing an integration right now, and my Disk utilization peaks at 26%. What worthwhile benefit would I get from going out, and Buying 32GB of RAM, and making a 24GB RAMDisk, and telling the Toolkit to use it? It goes to show that a RAMDrive is not some kind of silver bullet that's suddenly going to make the Toolkit make Windows images in a few minutes instead of an hour. The single biggest performance factor in relation to creating a Windows Image is actually disk access time, and random access time, not continuous disk bandwidth. To put this in plain language, the biggest performance improvement to WinToolkit is to use a good SSD. Yes you will get more performance from a VERY large (24GB) RAMDisk, but we are talking less than a 10% improvement for a fast computer with a good SSD.

Sounds like some interesting ideas Lego, Give people the power to do stuff the way they want it done. As long as you don't give yourself a brain fart making it happen :gleam: I do think DISM is the limiting factor here, at least on a high-end PC. But can you make the Toolkit handle all this stuff directly? Hats off to you if you can pull that one off! :prop:

Yeah, I agree, it sounds like that's what it's used for. I just wonder how much use a 20GB minimum sized RAM disk will be used. I will say it again, if you have 24GB of system RAM that your willing to make a 20GB RAMDisk with, and your still using a mechanical hard drive, you need you head examining! Upgrade your system! I cannot help test this, as I don't have 24+GB of RAM going spare. Otherwise it could be interesting to play with. I would still put money on not getting more than a 5% speed increase on a good system with an SSD. On a system with 24GB of RAM and a mechanical HD, the benefits would be huge.

I'm just throwing this out there for debate... Does anyone think that the Scratchdir command of DSIM could supposed to be used for debugging purposes, rather than speeding it up? As if it's run without the scratchdir command, wouldn't it just be doing it's work in RAM anyway?

Iv'e noticed that it's size changes all the time while the Toolkit is integrating the hotfixes. I guess it's only updated after each hotfix has been processed by DSIM, but on a mechanical HD, this would cause head thrashing, and would slow down performance on such a machine. But why anyone who has a system with 16GB or more RAM would be using a mechanical HD is beyond me.

Aaaaahhhh, I have found the REAL scratch directory, and can see how it works... Interesting that it only serves as a place where the hotfixes are decompressed to. Looking at the scratch directory only, a fairly small RAMDrive could be created, maybe 2GB minimum, 4GB recommended as a safety net to catch any larger hotfixes. One hotfix (KB2769165) got the directory up to just over 1.66GB. But for those wanting to cover all bases, the entire ToolKit directory in the Temp folder should be cached, as the cabs are decompressing outside of the scratch directory (C:\Users\Username\AppData\Local\Temp\WinToolkit). UPDATE... So WinToolkit actually has 2 folders (found so far) that are being used as a cache. The first one being C:\WinToolkit_Temp and the other contained in C:\Users\Username\AppData\Local\Temp\WinToolkit. A RAMDisk would need to contain both of these directories for performance sake, and would require a 16GB minimum RAMDisk partition, with 24GB being recommended. That's too rich for my taste, as the 2 or 3 minute gain is just not worth the cost in RAM. This is based on the fact that an advanced, or high-end PC uses a good SSD, so YMMV. Again, my observations on performance from my previous post apply. This is not the holy grail, I'm pretty sure of that.

Do we have any clue to a rough size estimate for the RAMDrive? How is the ScratchDir used? Is it only for decompressing CABs or is the whole Windows image compiled there? EDIT... OK, using the new v1.4.1.9, I have started a test integration, and have noticed a folder called WinToolkit_Temp in the root of my C: drive. I will work on the assumption that this is the scratch folder, if so, then it's peak size got to 10.6GB, this is based on a Windows 8 Ent x86 integration with only tweaks and 61 hotfixes applied... No addons. Judging by how large the temp folder got, it would be insane to use a RAMDisk, as you would need a system with more than 16GB of RAM, at least 24GB would be my recommendation, as the RAMDisk size would have to be at least 16GB, and maybe larger for some people that integrate schit-loads of large programs and addons. I still think that DiskIO (which on my SSD powered system, is running at between 0 and 21% disk utilisation during hotfix integration) is not the reason a high-end PC is slow at integrating. DSIM or maybe WinToolkit itself is the limiting factor, in my opinion. DiskIO peaks during the final stage of integration, while the image is actually being made, this part takes around 1 to 2 minutes on my system. The next operation that maxes out DiskIO is when you make an ISO image, this takes around 1 Minute, maybe 2 if it's a large image, over 6GB. Maybe a RAMDisk could help a lower end system (with a crazy amount of memory) that is still using a mechanical HDD, in this case, UPGRADE to an SSD, as it's stupid to run a high-end system with a mechanical HDD these days. BTW, this test integration took 23 Minutes on my system. No RAMDisk used. I would predict that I could have saved maybe 1 to 3 minutes of my life, if I was using a RAM disk. Maybe! System specifications: Intel i7 2600K @ 4.6GHz HT Enabled 16GB 2156MHz Memory, @ CAS 9 240GB Intel 520 SSD @6Gbps

My Hotfix folder is up to 977MB. Next patch day, it will more than likely be over the 1GB mark! It's just crazy how much of Win8 has been changed in just a few short months. Not good.

Maybe the way forward to make everybody happy, would be to add an option for error checking (defaulted to ON). That way if you just want to do quick tests, then turn advanced error checking off, then when your up for the final build, turn it back on.

Spot on! :prop:

Hi Caphp, you are right that an SSD will speed things up, as the random access times are near zero, compared to a mechanical drive, and a RAMDisk is even faster than an SSD. But I don't think diskIO is the real problem on a high-end system. I'm pretty sure it's DSIM, and how it's used in this case.

I'm pretty sure that disk utilisation is not the problem here. I have an SSD and a very fast computer, and notice that during integration, HDD access from the Toolkit is about 10%. Making Win7Toolkit use a RAM disk will only help those still using a slow mechanical HDD on an otherwise fast PC. The only part that is disk IO bound, is the image creation part, while making an ISO.

Thanks Rick, I tried again, and no more cookie problems with adf.ly.

Thanks for the update Ricktendo, but Adf.ly is broken in both Chrome and IE for me and many others.

Yep, Adf.ly is dead for me too. Both in Chrome and IE.

Hi Ricktendo, The SATA controller on your board is definatly SATA2, and may even support SATA3. Could you tell me what your board's model number is please?

Good luck with the replacement. Hopefully they will be nice and fast for you. Next time, buy an Intel SSD, not better service than Corsair, but much better hardware in the first place