Nazgul

You could try parsing the System Eventlog for events with the 7035 or 7036 Id, issued by the Service Control Manager to determine when services where started/stopped. You can also use the sc query command from a command prompt to get a list of currently running services.

There is a post over at RyanVM's forum which has a list of x64 hotfixes.

Is there a file called txtsetup.old present in your I386 folder? The driverpack scripts restore this to txtsetup.sif. If this restored txtsetup.sif doesn't contain all the changes made by RyanVM's pack your setup would indeed be screwed.

Two things that come to mind: - Did you change the SetupSourcePath in txtsetup.sif (this file is also present in your bootfolder!) - Try using a SP2 bootfolder. There are a lot of tools out there that will help you create one (like this one)

Could you verify that the security option "Network security: LAN Manager authentication level" is set to "Send NTLMv2 response only\refuse LM". You can also verify this by looking at the following registry key: HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel=? Where the number at ? should be 4 (or lower) If it's 5, this could be your problem.

It's still present in the copy_sys_files_to_temp.cmd. Shouldn't it be removed from there as well?

A small quote from Microsoft Windows Internals 4th edition: There aren't a lot of programs out there that are compiled with the correct flags to support a 3 GB address space, so this setting doesn't really have that much effect. It can even reduce performance, because system space is reduced to 1 GB, while most applications can only use the 2 GB of user process address space, thus in theory wasting 1 GB of virtual memory.(The only application i know for sure that are compiled with the correct switches are IIS and MSSQL)

You mean something like Windows XP PowerPacker?

The message tells you that there's something wrong with txtsetup.sif, so the first question you have to ask yourself is: Did I change that file? If so, what changes did you make and could you have made an error in them? Try comparing that txtsetup.sif with the original one and see what differences there are. And if there are differences, are they're all expected diferences. (You can use fc.exe to compare files or get a hold of a GUI based file comparison tool like WinDiff.exe)

I don't know if there is a method of doing that, but even then I wouldn't use it. There are a lot of valid reasons why you don't want Windows to use the entire RAM before starting to swap. I'll give an example: You have a number of programs running which use the entire RAM (and probably some swap space). When I start a new program Windows will first have to swap data from memory to swapspace and then load the new program into RAM before starting the new program. If we don't allocate all RAM we get: The new program gets loaded into RAM at once and starts. Windows then schedules a task to move some non-frequently used data from RAM to swapspace (at a slightly lower priority) to get the RAM usage under a certain threshold. Although the same amount of date gets moved to swap the second scenario appears to run faster for users because their applications start running earlier in the process.

Yes you can. I have a similar setup running on my development box. Keep in mind though that the more services you run on a single machine the more performance suffers, because they all share the same resources.

I'll give it a go What's the difference between the Alerter service and the Messenger service in Windows 2003, because the descriptions are pretty similair?

You can use Microsoft WinDiff which allows you to compare directories. Click here for a direct download.

If I understood Bashrat correctly, the only way to fix the portcls.sys error is by including all the different SoundMax drivers out there. So could you post a link to the drivers you used so Bashrat can include them in a next version of the DriverPack Sound, thus solving some of the problem.

The fact that you hav an 'outdated' patch on your system means nothing. At the time it was installed it wasn't outdated and although other patches have been installed since then that make the former patch outdated, the installation information isn't removed from the machine. Also, to check which hotfixes are missing from a machine, you can use HFNetChk or MBSA. If you want to run these tools on machines without Internet access, you just have to download the catalogs (the FAQ tells where you can find those) occasionally and copy it to that machine to have up-to-date scan results.

By starting with working through a few tutorials like: Creating an Unattended Windows XP/2003 CDCreating a Multi-Boot DVD DriverPacks tutorial DriverPacks MultiBoot tutorial You can also take a lot at the following tools to make your work easier: Windows XP PowerpackerBootFolder.exe Registry Tweakage DOTNET If you still have specific questions after working your way through those, we will be more than willing to answer those.

This topic is just to let you guys know that Microsoft has made a hotfix that solves the following problem: It took me ages to figure out what caused this issue on one of my machines, while the problems didn't appear on another machine with the same hardware (that one was running Windows 2000)

A registry setting that keeps Windows Calculator and the Character Map from modifying the win.ini file on exit. Credits to Aaron Margosis [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\win.ini] "SciCalc"="USR:Software\\Microsoft\\SciCalc" "MSUCE"="USR:Software\\Microsoft\\CharMap" And a key that makes the Administrators group the owner of new files made by an administrator, instead of that administrators account. (This is the default Windows 2003 behaviour and helps when running LUA) This tweak also by Aaron Margosis ;Make the Administartors group the owner of files instead of the individual Administrator account [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa] “nodefaultadminowner”=dword:00000000

Not bad, but these script won't work if you use BTS' MassStorage DriverPack or manually integrate your own MassStorage drivers, because your script doesn't take the new files into account. The best way to create a bootfolder is by parsing the dosnet.inf file. (Like I did with my BootFolder.exe) If you could change your batch files to do so, it would be a great alternative to my tool, because yours doesn't have any dependencies on the .Net framework. Also, why do we have to set the language abbreviation in your scripts? Because you don't appear to be using them?

What about the basic del command? del /q /s /f C:\SomeDir\*.bmp /q = Quiet mode, do not ask if ok to delete on global wildcard /s = Delete specified files from all subdirectories. /f = Force deleting of read-only files.

Although there aren't supposed to be double (or triple, or ...) entries in dosnet.inf, my application was partly at fault, because it gave an error and stopped copying, while it could have handled this situation gracefully.Because I expected the output folder to be empty (and check this in advance) I had set the overwrite bit to false. In this case my app tried to copy the same file twice and it failed to do so on the second copy because the file already existed. I've set the overwrite bit to true to fix this problem. I've also added a /f (force) switch which skips the 'empty target' verification, so you can run the program on an already existing bootfolder to update it. Keep in mind that this only updates new and changed files, but doesn't remove files which are no longer referenced. I've uploaded version 1.3 and modified the first post to reflect the updates mentioned here.

While this does work, it has a major disadvantage. It fails to take manually integrated textmode mass-storage drivers into account. By using either the BootFolder.exe or Winnt32.exe /noreboot option those driver changes are automattically integrated in your bootfolder.

Try BootFolder.exe. It's a program that will create a bootfolder identical to the one created using the winnt32.exe /noreboot method by parsing the dosnet.inf file. It can work it's magic on any Windows source folder independant of the Windows version installed.

Ok, I've just modified the first post and uploaded version 1.2 of my BootFolder tool. The changelog since version 1.0: 1.1 - Added 64-bit windows bootfolder support 1.2 - Reworked Copy code, because of instability with that code I'd also like to thank bombtrack and LispWarez for supplying me with the information I needed and for testing if my changes actually worked .

A typo in updatechecker_v506.cmd The label is called PU instead of CPU.