cluberti

I work in performance, core OS. Been doing it for years, back since Windows 2.0. I think I might know a thing or two about Windows .

Guys, a second-chance exception means the app crashed. If Zone Alarm self-generated a second-chance exception, it's most likely because internally it created a first-chance exception (internal error) that it couldn't deal with, so it crashed itself (aka a second-chance exception). So yes, ZoneAlarm is indeed at fault here.

As always, disclaimer I work for MS support. Just for reference, explorer.exe can (and does) run non-microsoft code. Since it's just the "wrapper" that launches all of the other goodies that display the user shell, get perm settings from GPO's, start user applications, verify registry settings, etc., it can also launch and be the parent of third-party applications - and when those apps crash, it's explorer.exe that LOOKS like it crashed (because the third-party app crashed and almost always brings down it's parent). To be honest, the absolute biggest problem with Windows systems is (irony drum beating here) antivirus software. Oh, and that's usually the reason why, after explorer.exe respawns after it crashes, that you may be missing icons from your taskbar (make sense now?). Edited because I can't spell .

First, disclaimer, I work for MS enterprise support. Second, you remove the everyone group from a critical permission location, and that's what happens. Stuff breaks. At least replace it with some other user group that's more secure (at least Authenticated Users). And last, yes, I've added hotfix 902400 to my XP install source without issue. Are you using something like nLite or some other tool, or just using the /integrate switch? Perhaps I can help.

Assuming you have a Windows 2000 or 2003 AD, you can use RIS and RIPREP to make images of your machines. If they can PXE boot (or have a NIC on the rbfg), you can do everything over the network. Visit the Unattended Windows portion of this board for LOTS more info.

First, disclaimer, I work for MS. Second, swap file - if you are only worried about performance, PUT THE SWAP FILE ON IT'S OWN PHYSICAL HARD DISK. Period. If you have two disks but use both, put it on the second disk. If you've only got one disk, you'd be best to keep it on the same partition as Windows. However, with that being said, if your system ever bluescreens and does a memory dump, unless the page file is on the same partition as Windows, you won't get any dump information about the crash - it's a Windows limitation. So if you need that info (say, to provide the memory dump to MS support... ), you won't have it (and may not be able to get it if you can't get the system to boot). Yes, for disk drive fragmentation reasons, it's best to make the pagefile one set size, min and max. And for those of you who disable the page file, that's a bad idea - part of the Windows kernel gets paged, whether you like it or not. And depending on the amount of physical memory in your box, it can be anywhere from 128 - 470MB of the kernel pagedpool memory that will be written to disk. Therefore, at least have a 500MB page file so that you can determine where the page file goes on the disk, and not allow the OS to put the page file somewhere on the disk that'll cause fragmentation. Yes, even if you tell Windows that you want no page file, it's still there - it has to be, or Windows would crash! Setting the no page file option just disallows any other app or service to use it (only the Windows kernel will be able to read and write to the page file).

I guess I'm biased in that I work for MS's enterprise support - but I'm surprised no one said Microsoft. I knew we were good, but...

Anything that uses the IE engine will use the MSHTML*.dll libraries. Outlook, for one, and Windows Explorer, for another. I wouldn't mess with those .

Get osverex from the zip file located here: http://internet.cybermesa.com/~bstewart/wast.html osverex.exe returns the OS as an exit code (11 for XP Pro), or the service pack level when run with the -s option. Easy to script.

"PAE will still limit each application to 4GB of virtual memory..." No, actually, the virtual address space for each process is limited to 2GB of memory unless you use the /3GB switch, which still only allows 3GB of memory. Just a nitpick .

symtdi.sys is part of the Symantec/Norton Internet Security suite. As per Microsoft, it isn't supported on Windows Server, and is known to cause problems. Assuming it's Symantec/Norton Internet Security, you need to remove the registry entries it created, then reinstall Windows Script 5.6 (yes, it damages Windows Script) by visiting http://www.microsoft.com/downloads/details...4b-4622-86eb-95 a22b832caa&displaylang=en - download and install WS 5.6 if possible. Then, delete the Norton/Symantec files found in C:\Program Files\Norton Internet Security and/or C:\Program Files\Norton Personal Firewall. Assuming you have no other Symantec products on the machine, you can also delete C:\Program Files\Symantec, C:\Program Files\Common Files\Symantec Shared, and C:\Documents and Settings\All Users\Application Data\Symantec. If you have other Symantec products on the computer, delete the folders C:\Documents and Settings\All Users\Application Data\Symantec\Norton AntiVirus, C:\Documents and Settings\All Users\Application Data\Symantec\Norton Internet Security, and C:\Documents and Settings\All Users\Application Data\Symantec\Norton Personal Firewall. Browse to the C:\Windows\System32\Drivers folder, and select the following files and delete the following files: Symdns.sys Symfw.sys Symndis.sys Symredir.cat Symredir.inf Symredrv.sys Symtdi.sys Browse to the C:\Windows\System32 folder, and delete the symredir.dll file. Close Windows Explorer and restart your server for the process to be complete.

The differences between all versions of Windows Server 2003 are listed here: http://www.microsoft.com/windowsserver2003...reeditions.mspx

If you've got Windows 2000, XP, or 2003, you can do a repair installation using the Windows installation CD. If you can boot normally, press ctrl+alt+del, select File > New Task, type "cmd" in the box (without the quotes), click OK, and get a command prompt, you can run the command "sfc /scannow" with the OS CD in the CD drive to repair the file as well. Otherwsie, you either need to do a parallel installation to copy over a good explorer.exe to your broken installation, or restore from backup (you do make backups, right???)

On server2, have you run "nbtstat -R", and also tombstoned the old server1 record on the WINS server?

If you post the call stack data (the rest of the goo in the error message, including numbers, names of drivers/sys files, etc., I can help you further). However, DRIVER_IRQL_NOT_LESS_OR_EQUAL is 99% of the time a driver that requested an IRQ level that was very high, or using an improper virtual address space address. Either the virtual address was in the pageable portion of the virtual address space, or the address didn't exist at all. What .sys file is listed in the call stack (it's usually on the top line of the numbers, at the far right)? That'd be the last driver loaded in the call stack, and your likely culprit... .

To answer your query, the default MTU for an XP box is 1500bytes. Therefore, for your 15000 byte ping, it takes 10 packets for that to be sent. Yes, you will see dropped packets and lots of latency when trying to send that much data over the wire in a ping - ping uses ICMP, and that size of a ping on most any network is just not going to work well. If you want to find out where the latency is, try monitoring your network with a monitoring tool such as ethereal (*nix/windows) or netmon (windows). Netmon is an easier tool to use, so I'd suggest that for you - you can find it at ftp://ftp.microsoft.com/PSS/Tools/NetMon/, and it's called netmon2.zip. Just pinging around your network tells you nothing about what's going on - you need at least a network trace of your internal network to know if you have latency (or other) issues for sure. Here's a question - how good is your antivirus and spyware protection on these machines, and how good really is that firewall of yours?

But most OEM's leave the driver files on the disk somewhere (I know Sony and Dell usually leave the c:\drivers folder on the disk), so you'd at least have the drivers to add to your $OEM$ share that the vendor used without searching for them on the vendor's site...

Cool - I have always installed MP10 and WMC one after the other with no problems - it looks like the MSI comes from wmcsetup.exe, but I'd be leery to use that. If wmcsetup.exe doesn't work, post back and I'll try to help from there.

It would take more time, yes, but then you don't have all of the useless CRAP that gets loaded on by OEM's on those PC's. Also, you'd have much better control over what was installed on those machines, making them easier to troubleshoot in the future if problems occur (no more guessing what is installed, what service pack on which application when, etc.). Plus, it's completely unattended - it's not like you have to sit and watch .

Br4tt3 is correct - the OemFilesPath is not valid in a RIS .sif file, and RIS will ONLY look in the $oem$ folder next to the i386 folder in the setup path. If you don't want all of your $OEM$ driver folders copied down you'll have to use WinPE to deploy your RIS images, or you'll have to create multiple flat file images and have separate $OEM$ folders for each hardware platform (this is my current solution, btw). Thanks to the SIS service, since all of the i386 folders for XP or 2K3 are the same, only one actual copy of each file in the i386 directory for each OS is actually stored on the drive, so disk space is not really an issue.

No problem .

Not entirely sure, everything looks OK. How about downloading wmcsetup.exe from (http://www.microsoft.com/downloads/details.aspx?FamilyID=56fd1b34-48ba-424b-9227-7c10e2e9fff1&displaylang=en), then using the command line: <path>\wmcsetup.exe /q I use that, and I've never had problems. Not sure where you got the MSI from.

There are variables already in the .sif file that point to the RIS flat image location - if you use those and modify them to point to your drivers, it'll work.

Not entirely sure - I think the net user command has a limitation of 14 characters without prompting. I've been able to use it in a domain environment (/DOMAIN) without a prompt, but not locally.

Autopartition = 1 That's the line that does it. Note that if you install over a network or via RIS, you would also have to add the line "Repartition = YES" to the [unattend] section.