cluberti

I can vouch for it being perennially bad

Not necessarily, but expanding your horizons perhaps gets you a better job down the line, and learning on the job (if one's employer will allow) is the best place to do so. And no, it's not that hard - most C and C++ code is in understandable English, and it's not hard to learn (how many bad programmers are out there? ) A good administrator IS at least a decent programmer - and since he'll be dealing mostly with problems being exhibited with Internet Explorer or caused by something done in IE, I can say that IE problems caused by 3rd party software are ALWAYS debuggable (although debugging IE bugs themselves are a PITA). You may be right - most of his problems will be spyware or virus-related, but what about that one time it's not? I suppose he could always waste an hour or two formatting and reinstalling (if the client will allow), but there are times in an admin's life when a problem just doesn't make sense and all the obvious things have been tried - debugging pulls back the veil and tells you exactly what is going on "under the hood", either doing a live debug or analyzing a process or system memory dump file. It removes guesswork when that's all that is left without the debugger. Again, I'll reiterate that a good admin is also at least a decent programmer, even if that knowledge is relegated to vbscripting, or perl, etc. I would also contend that not knowing how to troubleshoot BSOD's means a person is not a good Windows administrator (although that's just my opinion). I was just trying to expose something that's not hard to learn, and if he's got a job as a PC tech, he's probably at least mildly interested in learning more about the OS and how it works under the hood. It's not for everyone, but it is accessible by most with a very low learning curve to do the more menial debugging, which is likely going to be most of the cases one would debug as a first-line tech. I personally believe that it would stand to reason that learning some debugging skills on those types of cases is the best place to start, but the parent has every opportunity to simply ignore my post if he thinks that it would not be of assistance to him. I'm hoping curiosity gets the cat , but it's not for everyone.

First, I empathize with your plight. When activation fails, it really stinks. Second, however, is the fact that the version of XP you purchased with that machine is very highly likely a PC-vendor-OEM version of XP - this is expected behavior for one of those keys, and I'll explain. You will always be forced to call Microsoft to reactivate your XP install every time. This policy was instituted starting in February of last year, and all versions of Windows XP that are sold or bundled with PCs from OEM PC vendors to end-users are affected - no 6 month grace period (normally, you can reactivate after 6 months from a prior reactivation without issue, at least a few times before it fails completely). This is the reason why your activation is failing, unfortunately, and there isn't anything that you can do to get out of this activation loop short of actually purchasing a retail or "retail" OEM version of XP (and thus getting a non-PC-vendor-OEM key) from a vendor, either online or a brick-and-mortar store. Vista will be the same, so beware buying Windows with your computer if you're a frequent reinstaller, as you'll have to be more careful with your install. Reinstallation and reactivation will be a pain for anyone with a PC-vendor-OEM product key from now on.

When do you actually receive this error message? Also, have you nlited or otherwise modified your install in any way? All 0xc26x STOP errors are device driver errors, so it's likely a device driver (unsure which from the data posted) loaded itself where ntdll.dll needs to load, causing the bugcheck.

I do also think that the network card is another place to look - RIS is indeed very dependant on NIC drivers (obviously), and any idiosyncracies or bugs in a NIC driver can cause ALL SORTS of odd problems in RIS setups, that appear to have nothing to do with the NIC (like being unable to find a hard disk, or giving random BSODs during setup, etc).

I personally also vote for scripted RIS / WDS deployments, rather than disk imaging. As a previous poster said, imaging is definitely not better, but it is easier up front. But what happens if you need to add an application to your image? Or it starts failing to work on a new hardware platform? Or you find an error or security issue with it down the road? You have to basically start all over again when using most imaging software. RIS (now WDS with Vista - yay!) and ADS make client and server deployment easier and more configurable in the long run, but they are definitely harder to learn and get set up properly the first time for most new users - it is worth it though. Besides, those of us with ZTI RIS installs (yes, it is possible, and quite good when done) will have an easier time getting Vista deployed, as most RIS scripting works just fine in Vista, either flat or WIM files via ximage . Br4tt3 (and everyone else), note that Vista and Longhorn are language-neutral. Meaning that even English is technically a MUI, making this a moot-point in the near future. All code is language neutral, meaning a true 1-image solution for all languages. Just specify the language in the answer file, and viola! - a localized version of Vista in any available language from a single flat-file or WIM image...

I would go back to the i386 directory from a "clean" unmodified CD, and use nlite to integrate that. If you're getting that error on multiple PC's, it's very likely that one (or more) of the setup files are either corrupted or failing a CRC check (or both). In short, create a new CD with nlite, integrating only the RAID drivers, and see if that works.

Try running filemon and regmon while attempting to open your Office document, and see if there's anything in there out of the ordinary. Also, try using Autoruns (http://www.sysinternals.com) and ShellExView (http://www.nirsoft.net) to disable all non-Microsoft startup items/services and Explorer.exe shell extensions and see if the problem persists. A lot of times, these sorts of issues are caused by Explorer shell extension handlers misbehaving.

If you've got any programming or debugging experience (or want some), I strongly recommend the Debugging tools for Windows: http://www.microsoft.com/whdc/devtools/deb...ng/default.mspx The debugger NEVER lies .

Also consider searching the RIS forums here for answers - this is a pretty common problem, and has likely already been answered before over there. http://www.msfn.org/board/index.php?showforum=127

Honestly, I'm betting the kernel upgrade in the update you installed and rolled back caused one of your drivers or installed FSF drivers to go haywire. Since Windows works without dumping when you are in safe mode (which is the only true way to run windows without any 3rd party code), it's not likely that Windows itself is the culprit (anything is possible, but the likelihood is VERY low). I'd like to take a look at a complete memory dump from that machine the next time it happens, because it's probably a kernel-mode file system filter driver (or a service or running process calling into a kernel-mode fsf driver) causing the issue. Note that the 0xc0000005 value in the error code basically means that either the kernel denied access or execution of a kernel mode thread, or a running thread attempted to modify a protected area of kernel memory.

"OEM Files disappear ! The files from the $OEM$ are copied during the text-mode setup, but they disappear afterwards : I get error messages telling me setup can't find the files at the RunOnceEx step and, after checking, the $OEM$ files were really deleted !" Change the following line in your Winnt.sif file: FileSystem=LeaveAlone Then, install Windows XP onto a FAT32 volume. Once the text-mode setup completes, boot your PC to a bootable floppy disk or CD and check the drive to see if it indeed did, or did not, copy the files to your C: drive. "Ask user and company name during OOBE Following some pieces of advice found on this forum, I modified my OOBE file (expand, modified then makecab) to make Windows ask me for the User and Company name. But it didn't work..." Are you certain that your oobeinfo.ini file is located in $OEM$\$$\system32\oobe? If so, the fact that it isn't copying the $OEM$ structure is likely affecting this. "Regional settings at T-39 stage After modifying the OOBECONF.ini file to make it ask me for the regional settings, I'd like to make setup not to ask me for them at the T-39 stage, but I don't remember which file I have to modify... Can someone remind me please ?" Change the following line in your Winnt.sif file: OEMSkipRegional=1 "Help me protect my PC Following the ref.chm file, I modified the OOBEINFO.ini file so it won't ask for automatic updates anymore... It didn't work either." Again, change your Winnt.sif file: AutomaticUpdates=0

On the machine having connection issues, are the Workstation and Server services started and running?

I don't know how familiar you are with reading network traces, but installing the XP support tools (from the CD's \support directory) and running netcap on each machine while trying to access one machine from another would be of great help. Obviously there's something on your network blocking or intercepting these packets - a network trace would at least tell you a few things, mainly if the packets are actually getting from machine A to machine B, and if so, what machine B is sending back to machine A (and whether or not machine A sees THOSE packets). Somewhere along the way you'll see packets out from one machine and not returned to the other, which should at least help you determine which machine or hardware device is possibly at fault. If you are ABSOLUTELY sure there are no firewalls enabled on each machine and the Client for Microsoft Networks is installed on each machine, start the telnet service on each machine and see if you can telnet back and forth.

True - don't drink and post kids. Anyway, if you have a floppy image file (.img or similar) of the RBFG, you can use that as a bootable image for your CD. Just burn the .img file as the only file on the CD itself, and make the CD bootable with your CD burning software - pointing it to the .img file (and thus making the RBFG the bootable sector of your CD).

It's located here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{<GUID FOR YOUR NETWORK INTERFACE>}\DhcpIPAddress (it's a REG_SZ value). You'll find lots of other interface information here, updated every time the interface is refreshed (automatically or manually).

That sounds about right about the time you'd be sent over to Windows' text-mode setup. Is this a riprep image, or a flat image of XP x64? Also, if you have a flat of 32bit XP Pro, does it do the same thing on this hardware?

I currently use variations of the answer file below with no issues. Are you positive your video and communications drivers are installing properly during GUI mode setup? If they are not, those sections will fail. [SetupData] OsLoadOptions = "/noguiboot /fastdetect" SetupSourceDevice = "\Device\LanmanRedirector\%SERVERNAME%\RemInst\%INSTALLPATH%" [Data] floppyless = "1" OriSrc = "\\%SERVERNAME%\RemInst\%INSTALLPATH%\%MACHINETYPE%" OriTyp = "4" LocalSourceOnCD = 1 AutomaticUpdates = YES AutoPartition = 1 MsDosInitiated = 1 UnattendedInstall = Yes [Unattended] ExtendOEMPartition = 1 InstallFilesPath = "\\%SERVERNAME%\RemInst\%INSTALLPATH%\%MACHINETYPE%" LegacyNIC = 1 Unattendmode = FullUnattended UnattendSwitch = YES OemPreinstall = YES OemPnPDriversPath = drivers\audio;drivers\chipset;drivers\misc\wireless;drivers\modem;drivers\network;drivers\RAID;drivers\touchpad;drivers\video OemSkipEULA = YES TargetPath = WINDOWS Filesystem = ConvertNTFS DUDisable = YES Hibernation = NO WaitForReboot = NO DriverSigningPolicy=Ignore Repartition = Yes [GuiUnattended] TimeZone = 035 AdminPassword = ~PassWord1 EncryptedAdminPassword = NO OemSkipWelcome = 1 OEMSkipRegional = 1 AutoLogon = YES AutoLogonCount = 4 [SetupParams] UserExecute="%systemdrive%\temp\unattend.cmd %MEMORY% %SOFTWARE% %ADMIN%" [UserData] FullName = USER OrgName = ORGANIZATION ComputerName = %MACHINENAME% ProductKey = xxxxx-xxxxx-xxxxx-xxxxx-xxxxx [Display] BitsPerPel = 32 Xresolution = 800 YResolution = 600 [Identification] JoinDomain = DOMAIN DoOldStyleDomainJoin = YES [Networking] InstallDefaultComponents = Yes [NetServices] MS_Server=params.MS_PSched [NetOptionalComponents] Beacon = 0 [RemoteInstall] Repartition = Yes UseWholeDisk = Yes [Components] Accessopt = Off Chat = Off Deskpaper = Off Dialer = Off Fax = Off Fp_extensions = Off FP_Vdir_Deploy = Off Freecell = Off Hearts = Off IIS_Common = Off IIS_Doc = Off IIS_FTP = Off IIS_HTMLa = Off IIS_Inetmgr = Off IIS_NNTP = Off IIS_NNTP_Docs = Off IIS_Pwmgr = Off IIS_SMTP = Off IIS_SMTP_Docs = Off IIS_WWW = Off IIS_WWW_Vdir_Printers = Off IIS_WWW_Vdir_TerminalServices = Off IISDbg = Off Indexsrv_system = Off Media_utopia = Off Minesweeper = Off Mousepoint = Off Msmsgs = Off Msnexplr = Off Netoc = Off OEAccess = Off Pinball = Off Solitaire = Off Spider = Off WMAccess = Off zonegames = Off [PCHealth] ER_Display_UI = 0 ER_Enable_Applications = None ER_Enable_Kernel_Error = 0 ER_Enable_Reporting = 0 ER_Enable_Windows_Components = 0 ER_Force_Queue_Mode = 0 ER_Include_MSApps = 0 ER_Include_Shutdown_Errs = 0 [Shell] DefaultStartPanelOff = NO DefaultThemesOff = YES [SystemFileProtection] SFCQuota = 0 [SystemRestore] MaximumDataStorePercentOfDisk = 5 RestorePointLife = 7 [Branding] BrandIEUsingUnattended = Yes [URL] Home_Page = http://www.google.com Search_Page = http://www.google.com/ie_rsearch.html AutoConfig = 0 [OSChooser] Description="Windows XP Professional w/SP2" Help="This will install Windows XP Professional w/SP2" LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com" ImageType =Flat Version="5.1 (2600)"

I would suggest using Autoruns (from sysinternals.com) and ShellExView (from nirsoft.net) to disable all non-Microsoft startup items, services, and explorer shell extensions to see if the problem continues to occur. If it does, we'll have to get dumps of the process to see what is happening inside explorer.exe.

Have you tried your answer file without the quotes around the setting values, and without the extraneous spaces? Using the ProvideDefault profile can be quirky in RIS (whereas it isn't in sysprep and straight setup, for whatever reason).

You can boot floppy disk images via RIS with no problem - I personally use RIS menu editor from emBoot to make it easier - feed their application an .img floppy image, and it'll get it working in RIS for you. Much easier than making it work by hand http://www.emboot.com/products_RISME.htm Note that you'll need version 2.0 for Windows 2003 - 1.0 is Windows 2000-only.

Are you starting these installs via WinPE (or BartPE), or are these straight PXE-boot into Windows text-mode setup? If you're doing the former, this is expected behavior (unfortunately), and is made worse if you've got any file system filter drivers on the system (aka Antivirus software, backup OFO drivers, etc) that touch the RIS volume. If you use WinPE 2005 and the RamDrive option, this is alleviated, but most people don't go that far and run into this little gem. Not sure if this is your situation, but just so you are aware this is a problem with all PEs that do not use a RamDrive - if you aren't using PE, try uninstalling ALL file system filter drivers from that server and reboot to see if it helps. I can routinely get 50+ machines going at once on a single RIS server regularly, so what you are seeing is not normal behavior. The RIS server I use is used for nothing but RIS, has quite beefy hardware, and has no 3rd party software installed at all, mind you, but RIS is very robust if you treat the RIS install as a single-role server product.

From the horse's mouth (https://eopen.microsoft.com/EN/help.asp):

I would suggest removing the PC from the domain (so it belongs to no domain), and use secedit when logged on as the local administrator to reset default security. More info can be found here: http://www.microsoft.com/resources/documen...s.mspx?mfr=true http://support.microsoft.com/?kbid=313222

Before you can even begin to troubleshoot this, you need to know whether or not these are hard or soft page faults that you are seeing, and in what process(es) these faults are occurring. A hard page fault is a "true" page fault where the operating system needs to read data into memory from the disk in order to satisfy a request made by a running process for that data. These are the ones you usually see associated with page fault crashes in an application. A soft fault will occur when a running process tries to access the virtual location, or virtual address, of a particular data set, and the operating system was able to satisfy the request without reading in the page from disk. This happens most often with memory pages that the application wants to be zero (called ‘demand zero’ pages), when a page is written to for the first time (‘copy on write’ pages) or if the page is already in memory somewhere else (for example, moved to the area of memory that can be paged to disk if absolutely necessary - it's listed as 'paged' memory, but it's still actually in RAM). The last situation occurs if a file is memory mapped into multiple processes or into multiple locations of the same process, and one of the other file references has already caused the data to be written into physical memory or moved from one location to a different location, causing a 'soft" fault as the data is moved back to the location the process is requesting. You can ultimately see this one of two ways - you can use the NtQuerySystemInformation API to retrieve the SYSTEM_PERFORMANCE_INFORMATION structure, but this API isn't documented and will require reading of the web or a book called "Windows NT/2000 Native API Reference", by Gary Nebbett, to see how to do this in your application. You can also use the documented API GetProcessMemoryInfo (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getprocessmemoryinfo.asp) to gather page fault data in your application, but this API will not distinguish between hard and soft page faults, so it is of less use than the NtQuerySystemInformation API.