cluberti

From where did you download the installation package? It sounds like a bad download, or you aren't running SP3 or SP4 on Windows 2000 (required). IE 5.01 is included in SP4, so if you're running SP4 there is no need to install IE6 - it sounds more like package error. The download I would suggest is here: http://www.microsoft.com/downloads/details...;displaylang=en

Unless your usage patterns cause your system to use the swap file heavily (or you have a system with a low amount of RAM and a large amount of virtual address space committed), there really isn't a noticeable performance hit on faster (7200 RPM desktop or 5400RPM notebook) drives anymore regardless of the file's position. It matters more that it is contiguous, and moving it to a dedicated disk (not partition, disk) can help some, but with a decent amount of RAM your machine shouldn't be using the swap file for much more than file backing and moving idle pages in and out of RAM.

No check out the pic and what it shows. Geez, what does this mean? I don't have any groups and it says the snapin may not be used. Let me know how to fix this if you can can.....thanks. It means you've got Vista home, and can't manage users in a sane way and must use the silly control panel applet. Sigh. If you run system restore as administrator (right-click) do you get the same problem? If so, I'd run process monitor on the machine (again, run as administrator) and see where the "Access Denied" is coming from.

If you go into the user manager (lusrmgr.msc), you don't have an "administrator" (disabled) account?

The drivers are in the $OEM$ directory and exactly the same as the drivers that i use for SP2. I used a clean Windows XP installation CD with SP2 integrated. I slipstreamed SP3 in that setup, but I still use the original $OEM$. The problem is : - at T28 the file napclientprov.mof is missing. - After the installation the Firewall does not work properly - Screen resolution is not taken over from the unattend.txt - missing shortcuts for IE after installation. Assuming SP3 5512, napclientprov.mof issues are because wbemoc.inf has references to these files and they should be on the source, but if it's modified in any way (or the files really don't exist), then the error will occur (this was pretty common with slipstreams from SP3 RCs to SP3 RTM, where wbemoc.inf didn't get updated properly during the slip - not sure about slip'ing over SP2, but I suppose it's possible). It almost sounds like the drivers aren't getting installed completely. If you install the drivers on the SP3 source manually, do they work?

If you log in as the local administrator account (not just an account in the admin group, but the actual administrator account), does it work?

If the drivers are integrated, and SP3 doesn't work (but SP2 does), how are you integrating the drivers? Did you slipstream SP3 over your integrated SP2 source, or did you slip SP3 and then set up the drivers? Probably need to know a little more about what you're doing to get the drivers integrated into the source and more about the SP, and in what order things are being done.

Thanks Kel

No, it will not.

I do

*nix compared to Win9x, of course *nix will win because 9x doesn't really have a security model at all (including the flat memory address space, where any running app or driver can write into another app or driver's memory range - including kernel memory!). As to the NT-based OSes, it will depend on what OS you're talking about. If you compare NT4 to a modern Linux kernel+distro, it will be less secure on most fronts. However, if you compare Vista or XP, I think the comparison is favorable - XP and to a lesser extent Vista are out there in HUGE numbers, and are relatively secure (not secure, as nothing is truly secure if it's accessible on the public internet or a public network, but relatively secure is a good measure against usability). The security model of least user privilege, if followed, in general will leave XP and Vista machines pretty safe. Coupled with a NAT router or firewall between the client and the internet (or host firewall and other machines on a public network), Windows is basically going to be basically protected against most (all?) remote active attack attempts (especially if the firewall is configured well, as it should be for all machines and networks, not just Windows). However, the user is the weak link (especially with Windows, as more knowledgeable/savvy users are using *nix, whereas anyone and everyone seems to use a Windows box), making social engineering and "passive" (open this file and win a prize!!!) type attacks still work much easier than in *nix, due to the inherent nature of a much more agressive (and perhaps usable, but I won't get into that) model for LUA in *nix versus Windows (where everyone runs admin, partially because a lot of software requires that level to work - self-fulfilling prophecy in reducing security of the OS).

Unless you have a .net app on your box that requires one of those versions. They aren't cumulative, so if you want to use a .net 1.1 app, for instance, you need .net 1.1 installed.

Your problem is actually a somewhat known issue with HP/Compaq AMD machines - they build their images they deploy with the Intel power management drivers installed (intelppm.sys) - if you can boot in safe mode and disable this device driver (or the recovery console to do the same), you can get it working. This is HP/Compaq's mistake, not a problem with SP3 (the intelppm.sys driver gets updated, and starts sending the AMD machine power management instructions it does not understand, causing the crashes).

According to what I am seeing, this is almost all being caused by disk I/O in the system process (the kernel) - also, you have !!!2012!!! threads in the System process during boot (I have a Vista Ultimate box that runs under 100!!! threads here), so that is definitely not normal. I think we need to start investigating drivers, including antivirus, or firewall, or antispyware, or any other software packages (including hardware drivers) to see what could be causing 1) all of that disk I/O, mostly reads, from the System (kernel) process and 2) why the heck you have so darn many System threads. That is most certainly NOT normal.

You could download and install userdump, create a rule that dumps explorer.exe every time it crashes, and then the next time it occurs perhaps upload it somewhere we can look at it. It would save you a rebuild if the problem is fixable. Note that if you cannot run explorer.exe, you'll probably have to open safe mode with networking and use the task manager to start iexplore.exe to download the file, and the task manager again to run the installer. Here's how to get it working. 1. Download and run UserModeProcessDumper8_1_2929_5.exe (from the link above) to extract the setup for the tool. 2. Run the setup.exe from the x86 folder where you extracted in step 1 (I'm assuming this is an x86 copy of XP), making sure to select the "Enable 'Dump on Process Termination' feature" option when prompted during setup. 3. When prompted "Do you want setup to take you there..." after the install is complete, click the "Yes' button to open the Process Dumper applet. 4. Click the "New..." button, and enter "explorer.exe" (without the quotes) in the "Application name:" box, then click OK. 5. Click the "Rules..." button. 6. Click the "Use custom rules" radio buton, click the "All Exceptions" box, change the "Dump file folder:" box to point to a temporary directory (other than C:\Windows) to store the dump files generated, and click the "Monitor Process Exit" box and select the "Complete" radio button for "MiniDump Type:" underneath. Then click "OK" to finish. Reboot, and when explorer crashes, you should have at least one .dmp file in the directory you typed into the "Dump file folder:" box in step 6. Compress and upload, and we can take a look.

If you've still got a beta, and not the RC bits, you can try to copy the contents of the integration ISO's driver structure into \system32\drivers and update the unknown device (the VMBus driver) by pointing to \system32\drivers - I haven't run the beta in awhile, but I seem to remember something like this working on W2K...

The drivers are synthetic drivers, not actual drivers, so without the Windows Driver Model update you can't use them (and W2K isn't going to get that update, it's in extended support and the package is a non-security update). The short answer is, not supported .

That hotfix is included with SP3, so analyzeforbranching on it is going to fail (and it will fail to install). How are you integrating IE7? It's been known that integrating IE7 into an SP3 source ends up with IE7 files in \system32\, but IE6 files in \system32\dllcache (and some people have resorted to deleting the contents of the \dllcache\ folder post install to fix it...).

Standard and Enterprise share the same memory management functions in the kernel. However, there are differences between the two you do want to be aware of (I think this is what he meant by "memory management" differences).

If you've got an XP source i386 folder, simply slipstream SP3 into it and then add it to RIS (either manually or with the wizard - I prefer manual, but that's just me). Working OK here on a few boxes.

lol Check your PM

Vista x64 has pretty good driver support (*cough*Nvidia*cough), but XP/2003 x64 is still somewhat lacking (not as bad as before, but it can still be a bit of trial and error). Unless the x86 application has specific hardcoded information for filesystem or registry that do not exist on 32bit, has a kernel filter driver, or tries to use AWE or other such memory tricks, it should work just fine on an x64 version of Windows. This is not always true with games, but for other software, it is - games you should definitely check around before trying on x64. In that vein, however, you will need 64bit antivirus software, for instance, because it uses a filter driver (most 3rd party firewall software does as well, so you would need a x64 package of that as well).

Hope you had a happy birthday mate!

mmmmm cake Happy bday mate!

It may not stop them, but it'll give you time to deal with the problem before you actually get hacked (you now have an early-warning system in place).