Siginet

@Bashrat Please re-read my second post in this thread. I have found something else that needs to be fixed. I am trying to find where in your script you are placeing those entries so I can post the fix for you... just incase you don't get to it first.

Testing now. During slipstreaming MassStorage DP I get this error: Bashrat the Sneaky's DriverPacks Slipstreamer - STEP 3 [DONE] A) cleanup [BUSY] B) slipstreaming DriverPacks C) settings _ [M2] DriverPacks slipstreamed... _ [M2] necessary files copied... _ [M2] replaced real setup by a fake one, copied presetup.cmd... _ [M2] WINNT.SIF file updated... _ [M2] TXTSETUP.SIF and DOSNET.INF files updated... _ [M2] DriverPack MassStorage slipstreamed... 2005/07/03 13:53:22 ERROR 3 (0x00000003) Accessing Source Directory C:\D_C_TMP\D \C\I\ The system cannot find the path specified. The system cannot find the file specified. _ [M2] Intel Chipset .inf files copied to $OEM$\$$\INF... _ back-up of portcls.sys made... _ KB888111 slipstreamed... ################################################################################ Press any key to continue . . . Is that normal? I will finish the process and test it. Edit: I think I had a curropt chipset DP. I re-downloaded it. Edit2: I still get the same error with the newly dled chipset DP.

I get the same issue. But the problem is not there If I don't use the DPS. I am trying to create a disk without the PowerPacker now. Edit I think this issue might be caused by Multiple instances of files in the dosnet.inf file. Which I don't think normally causes too much of an issue. So far these are the multiple instances I have found in the dosnet.inf file: Multiple instances in the Dosnet.inf aliide.sys hpt3xx.sys dac960nt.sys mraid35x.sys ql12160.sys ultra.sys adpu160m.sys dpti2o.sys dac2w2k.sys After I remove the multiple entries from the dosnet.inf file... BootFolder.exe works correctly and allows all boot files to get copied to the Boot Directory. Only people creating multiboot disks may come across this error. Edit2: REMOVED This doesn't seem to help... I am trying something else. Edit3: It seems to be an Fedit error. REM ### DOSNET.INF method part. ### ECHO Editing DOSNET.INF... REM Removing old entries. SET T1=Fedit -rem -f I386\DOSNET.INF -s Files %T1% adpu160m.sys %T1% aliide.sys %T1% dac2w2k.sys %T1% dac960nt.sys %T1% dpti2o.sys %T1% hpt3xx.sys %T1% mraid35x.sys %T1% ql12160.sys %T1% ultra.sys This code doesn't seem to be working? It isn't removing the old entries.

It looks like there is an error in the RUN_ME.CMD file which is causeing the above problem. Edit this: ROBOCOPY "%CD%" $OEM$ cmdlines_fix.exe /MOV %RS% > NUL START /WAIT cmdlines_fix.exe DEL /Q cmdlines_Fix.exe With this: ROBOCOPY "%CD%" $OEM$ cmdlines_fix.exe /MOV %RS% > NUL START /WAIT $OEM$\cmdlines_fix.exe DEL /Q $OEM$\cmdlines_Fix.exe Edit: I have confirmed that this does indeed fix that problem.

Congrats! It was a long week for us! But we finally found the issue. moesasji and I spent quite a few long nights over msn messanger trying to figure out the problem. A huge thank you to him... because without his patience the issue may have never been found.! Thanks moesasji!

I am the one who created PowerPacker I have been trying to figure out a bug that one of my beta testers had run into for about a week. No matter what we did we could not figure out why he was having an issue. We just found out that the cmd mod and a tool I use in my program called BootFolder.exe where not working well together. As soon as he uninstalled the CMD mod all worked fine. I just wanted to point out the issue. I haven't used Xpize yet... but it sounds very interesting. Hopefully maybe you can use my program as a test tool to find out why cmd mod does not like it. I noticed most people never had a problem with cmd mod... so that makes it hard to fix an error. At least with my tool you can see if you can re-create the issue.

I think he means... Grab the contents of d1 and make an image... then inject the contents of d2?

I haven't tried it personally yet. But I am also curious as to how well it would work. I also wonder how well 2003 will work.

I used to create my builds without the mass storage DP... But recently they have gotten pretty good. I have edited the DriverPack batch files to fix the problem you are posting. If I can recall what I fixed I will post it. I usually do 3 different Packs for each OS Version/Edition. One Unattended with DP, One Unattended W/O DP, and one Regular W/O Unattended and W/O DP. This way if I come across a system that does not like the DP I can choose the option W/O DPs. Or if I need to use Windows XP repair I use the Regular load. I have been thinking about adding another option to PowerPacker to create a Tri-Pack which would automatically create all three packs in one run. But that is hopefully for a release some time in the future. BTW... That sucks if Symantec 9.02 is the culprit! I currently use Symantec 9.03 and I have no probs. But hopefully we found the issue. Somehow I have got to fix the code so that doesn't cause a problem. Cause I wouldn't want to turn off my AV for anything.

The hptmv6 is caused by the Mass Storage DriverPack. It is a flaw in the newest version of the DriverPacks. More info can be found HERE. This error is not related to the PowerPacker program. I tried to email you to let you know... but You must not have received my email? As for the txtsetup.sif and setupldr errors... I can't figure out why you get these errors with the original PowerPacker V1.06. I am wondering if it has anything to do with user permissions on the computer itself? Maybe there is an AntiSpyware/Antivirus program killing part of the script?

I've tried to re-create this error on multiple computers now and I can't seem to do it. Every computer I try it on does the job perfectly. I'm not saying the bug isn't there... but it is kind of hard to re-code something when you don't know exactly where the problem is. I will keep trying it on every computer I get a chance to try it on... and I will try to better the error checking code in the program.

OK... I have now tested on 2 more different computers and everything went through ok. I used the Original PowerPacker v1.06. I am going to try to re-create this error on another computer now. @All I need extensive testing to help me work out this issue. Please post here any problems or success storys about my PowerPacker tool. Thank you to all Beta Testers! I really do appreciate it.

Removed this post. Posted it here by accident.

Let me know how it goes. moesasji and I were on msn messanger and he still had the same problem. But when he tried it on a slower computer 800MHz and it worked fine. This is really weird. Because my computer is a 3700+ Athlon 64. Which is very fast. moesasji's computer is a 1.8 with 1gb ram. Yours is a 2.8GHz. I think you need .NET installed to use the bootfolder.exe version... but moesasji has it installed. I can't seem to re-create this problem on my computer. I will try to go to my office tonight and test it on a few computers there.

OK I went ahead and grabbed some of my old code and replaced some of the new code. This version is not using BootFolder.exe to create the boot folder. It is using the regular winnt32.exe. Therefore it will seem as if it is installing windows xp... but really it is only grabbing the needed files to move into the boot folder. I reccommend most users to use the regular PowerPacker file... but if you are having difficulty createing the boot folder with the original PowerPacker than you can try this one. Here is the winnt32.exe version of PowerPacker v1.06: DOWNLOAD

Now when you are re-trying to make a pack... are you just having powerpacker overwrite files.? Or are you deleteing the destination directory then using powerpacker? I know BootFolder.exe will not work if there is allready files in it's destination directory. You said there is a winnt.sif file in the directory. Try at least deleteing the ROPC/XPPC/XOPC folders from the root of your destination. Then retry the program. All I can think is that there is some sort of limitation with the bootfolder.exe tool and the way your system is tweaked. If that is the case there is not much I can do. Except if I have time I can use some of my old code which does not use the BootFolder.exe file but runs the first part of windows setup to get the files. Which takes a little longer but will get the job done just the same.

OK... new version released. Beta version 1.06 Download HERE or go to the first post of the thread and find a download link at the bottom. Fixed a few minor bugs. Also coded the temp directory a little differently. Added the newest version of BootFolder.exe This version of powerpacker was created to hopefully fix moesasji's problem. (Which is a problem I can't seem to recreate at my end. So hopefully this will help.) @moesasji Please try the new version and let me know if that fixes your problem or not.

That is not the normal XP temp directory. It is usually: "C:\Documents and Settings\USERNAME\Local Settings\Temp" or %TEMP% = "C:\Documents and Settings\USERNAME\Local Settings\Temp" When you run %TEMP% it sends you to "C:\Temp"? Well... I will edit my script and see if that will help.

Did you have any luck?

OK... the problem lies with the BootFolder.exe somewhere. I am going to look into it further and try to figure out why you are having a problem here. What OS are you using. Is it XP/2000? If so it shouldn't have a problem. If it is Win9x then maybe... cause I have never tested on that syatem. But in theory it should work fine on 9x series. For some reason the boot folders are not getting filled with the proper files. That is why you get errors durring the hexing part. That is also why you get the ntldr error. Because those files are not getting copied over. The question is... why? Can you do this: Go to your [RUN] box and type: %TEMP% then hit enter. In the temp directory do you see a file called "BootFolder.exe"? If you don't see the file... I will make a quick mod to the app and post a fixed version online for you to test. Thanks for your patience

Which method are you using? Method 2 is what I personally reccommend. RunOnceEx or GuiRunOnce? I use RunOnceEx method. KTD Yes or No? Either way should be fine from what I have experianced. Try installing the driverpacks without the sound drivers and try to load the laptop. If that fails try removing the mass storage ones. This way we can narrow the problem down. I say Sound/Masstorage ones because those are the most troublesome ones I have had experiance with latley. If the problem is not in those packs try to remove others. If it is a driver issue with the laptop we need to find the error so Bashrat can try to fix it in the next release. Also... you are using a DVD. Is this a multiboot setup? if so... how much space are you using on the DVD? How many OSes are you using. Try burning the DVD at the slowest setting... and/or try different media as well. Sorry for all of the questions... but these are all areas that can be looked at.

OK according to your cdshell.ini it looks like it was edited as it should have been. Now inside of your folder "G:\PPOutput" there should be 2 folders XPPC and ROPC. Can you grab these files and zip them and post them for me: G:\PPOutput\XPPC\txtsetup.sif G:\PPOutput\XPPC\setupldr.bin G:\PPOutput\ROPC\txtsetup.sif G:\PPOutput\ROPC\setupldr.bin G:\PPOutput\XPPC.DAT G:\PPOutput\ROPC.DAT Earlier you stated that you had a couple errors. Can you remember what errors they were and when they occured. Was the error in a dos window or a windows XP window. If you can... can you post some screen shots of your directory structure? Thanks

Does this program also work for Win2003 VLK? <{POST_SNAPBACK}> PowerPacker is made for WinXP. I have not tested it at all with 2k3. All of the options were made for XP... but you could try 2k3 using an xp option and see what happens. BootFolder.exe is a tool made by Nazgul. It is what parses the dosnet.inf file. It is compatable with 2k3. You can find it on msfn.org forums by using the search feature.

Edit: Double post. Sorry

basically if you do not press enter it is supposed to boot to hard drive 0. If you press enter it should boot to the selection menu. Here's what I need you to do... look inside the \boot\ folder and find a file called cdshell.ini. This is the menu file. zip it up and attach it here so I can look at it. Somehow it seems like it had trouble editing the cdshell.ini file. This is the first issue I have come accross since the end of may. So maybe you found a bug that will actually give me something to do. BTW Did your paths have any spaces in them? I don't think spaces would be a problem with my apps side of things... but with the driverpacks or any other tools used this may be an issue. Any limitations you would have with any of the other programs, (RyanVM's XP Update Pack, Nazgul's BootFolder.exe & Bashrat's Driverpacks), would also be the same with PowerPacker. Thanks for posting. EDIT: I have confirmed that you can not have any spaces in the destination path. If you have spaces in the destination you will come across problems when the tool bootfolder.exe runs. BootFolder.exe is supposed to create your boot directory. If it doesn't create the directory... then the other hex editing does not complete... which means the cdshell.ini file does not get edited and your boot menu will not work. Which is more than likley the problem that you have run into. But please note... the driverpacks are known to have issues with a path which contains spaces. So please try again... but with no spaces in the destination path. Spaces should be fine anywhere else... but the destination must not have spaces... due to the limitation of other tools that are used within PowerPacker. I may add a popup reminder that will pop up if someone tries to put in a destination path which contains a space. Thank you for posting this bug. Please post again and let me know if I found the problem or not.