cluberti

This file is either from Sonic Solutions' DVD software, or from Veritas (go figure). However, this is almost always caused by a device driver or hardware problem, so the file listed here may simply be the victim of some device driver (or bad hardware) passing an invalid header into kernel memory (which is where your paged pool and nonpaged pool memory pools are located). Tracking this one down will likely require you to strip the machine down to the basics (RAM, processor, video, hard disk) and keep adding hardware and rebooting one device at a time until the BSOD returns. Good luck...

If you've installed WSUS, it provides both the update and statistics server components. SUS 1.0 didn't provide the statistics components, but you can still put the FQDN in both boxes with either server - things will work fine either way. Just put your WSUS's fully qualified domain name (FQDN) in both boxes, and you'll be fine.

OK, so I'm going to need a complete dump of the OS when it bluescreens. To do this, go into the Properties of "My Computer", then click the "Advanced" tab, click the "Settings" tab under the "Startup and Recovery" heading, and then select "Complete memory dump" under the "Write debugging information" heading. You will need to make sure that the page file is at least the same size as the physical memory in the machine +50MB to make sure the dump isn't corrupt. Once the system bluescreens after making this change, it will create a memory.dmp file in the Windows folder. This file should be the same size as the amount of physical memory in the machine - if you compress this and send it to me or post it here, I can then run it through a debugger and get some "root cause" information.

Read the first post again - that's how you do it.

I'm seeing winlogon errors, eventsystem errors, and DCOM errors through the roof. However, the bugcheck isn't registering with the event logging subsystem (due to the aforementions eventsystem errors, apparently), so the next time the box bluescreens PLEASE write down the information onscreen (including the numbers). Otherwise, I won't know what's going on unless you are willing to attach an external kernel debugger to the system via another PC connected to the COM port via a null-modem cable and setting up the machine to run "checked" or with the /debug switch in boot.ini. I'd say it'd be easier just to write the bluescreen info down . By the way, the DCOM 10016 event references CLSID {BC866CF2-5486-41F7-B46B-9AA49CF3EBB1}. If you look in your registry under HKCR\CLSID\, you should have a key with the above name. Follow the instructions in KB article 899965 (http://support.microsoft.com/?kbid=899965) to fix this issue. However, I doubt this is related to your bugcheck issue, it's just another problem I see on the system.

In your DHCP server, add the following options: 066 (Boot server host name): server.domain.tld 067 (Bootfile Name): \OSChooser\i386\startrom.com Those values in your DHCP server will point the BOOTP and TFTP requests to your RIS server. Note that even if you are using a Windows DHCP server, you should still add these options to your scope. However, unless you absolutely NEED the Cisco to be providing DHCP for your subnet, it would be better to simply enable DHCP passthrough on that router, and configure a new scope for this subnet on your Windows DHCP server. Contrary to popular belief, you do not need a DHCP server for each network subnet - and to be honest, it's easier NOT to have multiple DHCP servers on your network. Having a backup might be necessary for single point of failure issues, but for most networks a single DHCP server with multiple scopes works just as well as multiple DHCP servers for each subnet.

I've always used a script to copy files from C:\TEMP\icons ($OEM$\$1\TEMP\icons) to C:\Documents and Settings\All Users\Desktop during RunOnceEx. I think it would work in a script run from [setupParams] at T-9 during setup, but I'm not sure about copying these files over beforehand. The entire system isn't completely ready to go until the T-9 mark, so copying files to the All Users folder may or may not work before that. I'd suggest at least trying the [setupParams] or RunOnceEx methods to copy pre-existing .lnk files from a temporary location to the All Users\Desktop folder and see what does, and does not, work.

The activation count used to expire after 6 months, but I believe this has been discontinued and activations are now remembered longer than 6 months - which is likely why you ran into this little snag. If you use a full OEM version of Windows (not retail, not OEM as in comes with an OEM PC, but a real, full OEM version) you will not have to activate Windows. This will likely change with Vista, but XP OEM versions do not need to be activated.

If the computer is added to the domain, you can't change the name with a local administrator account because you are then modifying not only the local name, but the actual computer account in Active Directory (which a local admin account does not have rights to do). Once that machine is removed from the domain, the local admin can change the computer name again. As to changing the name of a domain-attached computer, the user must have privileges both in AD _AND_ on the local workstation, because the name change takes place in BOTH places. There is no way to delegate the local computer name change right in AD, and thus local admin privileges are required on top of the AD permissions to actually change a computer name.

Both files contain FAKE keys. The one that is on your computer CASE is the real CD key. For the two files in question, they'll likely say "sample" near the top of the file, along with some Microsoft copyright information. If this exists, those are indeed SAMPLE files with keys that are fake.

Stop: 0x000000F4 has a reference value of CRITICAL_OBJECT_TERMINATION. This means that some process or thread critical to OS function terminated unexpectedly (probably a second-chance exception), which in turn caused the operating system to become unstable and bugcheck. There is a good MSDN article to read that gives more info on that particular bugcheck value that I suggest you read, as it gives you some more insight as to what is actually happening when you get this error: http://msdn.microsoft.com/library/default....6b95c57.xml.asp If you could post here the actual output of the bugcheck error message (you can find it in your event viewer if you can't get it from the bluescreen message itself), including the terminating object type (0x3 - process or 0x6 thread), the terminating object itself, the process name, and possibly the ASCII error message at the end, that would be extremely helpful data so I can begin helping you track down the problem code.

If windows detects that it has loaded the default VGA driver (or the Microsoft-supplied driver for your video card) and the display is less than 800x600, you WILL get this display. If you are installing your video drivers in OemPnpDriversPath (or Windows already has a driver for your card), try setting your resolution to 800x600 at 32 bits. As long as a Microsoft-supplied or 3rd-party video driver is installed, this resolution will result in no display message.

Try adding this switch to the end of your install: /DisallowSystemRestore

These aren't publicly available, so unless you know someone who already has it, you'll have to call Microsoft and have them send it to you.

The key can be added in Group Policy, as well.

As to adding workstations to the domain, in your GPO under Computer Config > Windows Settings > Security Settings > Local Policies > User Rights Assignment, there is an object called "Add workstations to domain", which is just what it sounds like. You will also need to delegate the permission to create computer objects and delete computer objects in the OU where the workstations reside to the group you are adding these users to. As for changing machine names, your users would need administrative rights on the workstation itself, so allowing machine name changes may not be possible in your environment without adding the user to the local machine's administrators group.

1. In your Windows Update container in Group Policy, make sure you have the following set: a. Configure Automatic Updates: Enabled - Configure automatic updating: 4 - Auto download and schedule the install b. Scheduled install day: 0 - Every day - Scheduled install time: 03:00 (3AM) c. Specify intranet Microsoft update service location: Enabled - make sure both boxes have the correct FQDN locations for your WSUS server - for example, http://server.mydomain.com - using netbios names can be problematic d. Automatic Updates detection frequency: Enabled - Check for updates at the following interval (hours): 1 - Allow non-administrators to receive update notifications: Enabled Set other policy values as you see fit. 2. If you've got multiple DC's, make sure that the policy has finished replicating or force a replication using the AD Sites and Services mmc snapin. 3. Make sure you've updated your group policy on the computer in question (gpupdate /force), and restarted just to be safe. 4. On the computer in question, enter the following commands from a command prompt: net stop "automatic updates" net stop "background intelligent transfer service" del %windir%\windowsupdate.log del "%windir%\windows update.log" net start "background intelligent transfer service" net start "automatic updates" 5. Wait 15 minutes, and check your %windir%\Windowsupdate.log file to check the status of your client connecting to the WSUS server. Once you're sure it's working, you can tweak the values to set the time, auto-install, etc. to better match your environment's needs. Good luck.

You could always just copy the deltree.exe from a Win9x CD to the system32 directory on your box. Deltree does work in XP. It is also downloadable from http://www.uv.tietgen.dk/staff/mlha/Download/DOS/ (lots of other DOS goodies there too).

That looks correct, but I've got a better solution that cmdlines.txt that is less prone to error (at least for me ). Place your runonceex.cmd file in $oem$\$1\TEMP on your CD, then in your Winnt.sif file, use the [setupParams] section to call your script: [SetupParams] UserExecute=%systemdrive%\temp\runonceex.cmd This will execute at T-9 during setup, with no need for a cmdlines.txt or any other files to keep track of.

The "My Documents", "My Computer", "My Network Places", "Recycle Bin", and "Internet Explorer" icons are special icons - they are hidden or shown on the desktop based on registry keys (they are not .lnk files!). Therefore, if you want to show the above icons on the desktop, you will need to modify their corresponding registry keys and values (as previously posted) to get them to be visible on the desktop. If you have other shortcuts of your own that you'd like to show on the desktop, simply create the shortcut files on another system, copy the newly created .lnk files to your CD, then copy them to the desktop during installation.

This could probably be done if you use WinPE to start your Windows setup. Have WinPE boot, require the user to enter a code, then continue the installation if the code is correct or fail and reboot (or whatever) if the code is incorrect. However, I'm not sure you could keep users from simply copying the i386 directory and making their own CD's from it. If your technicians are using these CD's to install Windows on PC's that can be overwritten, you can do the following on a test PC to achieve a fairly good level of encryption of both the install and the CD's contents (you'll need a template machine to do this on, and a Win9x boot disk or CD): On the template machine: 1. Create a 4GB FAT32 volume (C:) 2. Copy the contents of the i386 directory from a Windows CD to the hard disk 3. Copy any other directories and files you'd need to the hard disk 4. Install DOS system files to the C: drive via the Win9x boot disk or CD by using the "sys" command 5. Copy config.sys and autoexec.bat from your Win9x boot disk or CD to C:\ 6. In the autoexec.bat file on C:, place the command at the end of the file: C:\i386\winnt.exe /s:c:\i386 /u:c:\i386\unattend.txt - for the above command, substitute your unattend.txt file's location if it is not in C:\i386 7. Use Symantec Ghost to make an image of the C:\ drive, password protecting the image. 8. Create a bootable CD, which will extract the Ghost image when given the correct password (created in step 7) to the hard disk and restart - since this is documented in many places on the 'net, including in the Ghost documentation from Symantec, I won't rehash it here. 9. When the drive has been imaged via the boot CD and restarted, Windows setup will begin using the command line entered in step 6. You can also use Acronis DriveImage in place of Symantec Ghost (or any other drive imaging software that can password-protect image files) - if the above method is followed, you should have a password-protected image file that will only copy Windows to the disk once the password has been entered. Symantec Ghost 10.0 will also encrypt your image, if you so choose. Just remember that once the image has been extracted, even a novice tech can copy those files and use them. There is no sure-fire way to protect the Windows installation routine short of the product key itself. If you have third-party code that you want to protect, consider password-protecting that and compressing it into a .cab or .zip that is run AFTER Windows has been installed - that way, you can leave it unencrypted on the CD (and not have to go through the hassle of ghost, encryption, etc.) and still have it password-protected for use, whether on the CD or off. Again, even in this configuration, once the files have been extracted to disk to be run, they can be copied off and used elsewhere by even a novice tech. Good luck, and perhaps someone smarter than I already has a better solution!

Once you are able to get to the desktop, install "Process Explorer" from http://www.sysinternals.com and see if there is any process (or processes) using up large amounts of CPU or memory. Since the system does eventually boot (albeit slowly), my guess is the Antivirus software or perhaps a device driver causing an interrupt issue over the USB bus. If you can disable the USB bus completely in the BIOS, that would be a good step to troubleshoot as well.

That's the .net framework 2.0 - http://www.microsoft.com/downloads/details...&DisplayLang=en. Hint - if you looked at the "More Details..." link of the update, it directed you to the .Net framework page on the Microsoft site, which had a link to download the redistributables and the SDK...

That is precisely the reason. Also, if sfc asks for the CD, it means it found system files that have been modified or are not checksum'ing, and they need to be replaced from the CD. Any time you install a new service pack, you should slipstream your original OS installation CD for this precise purpose.

Save this as desktop.vbs and run it. It will auto-arrange icons on the desktop. ' *** Begin Script *** ' Registry constants Const HDI_CLASSIC = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\ClassicStartMenu" Const HDI_NEW = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel" Const MY_COMPUTER = "\{20D04FE0-3AEA-1069-A2D8-08002B30309D}" Const MY_NETWORK_PLACES = "\{208D2C60-3AEA-1069-A2D7-08002B30309D}" Const MY_DOCUMENTS = "\{450D8FBA-AD25-11D0-98A8-0800361B1103}" Const INTERNET_EXPLORER = "\{871C5380-42A0-1069-A2EA-08002B30309D}" ' Edit registry to show all icons With CreateObject("WScript.Shell") .RegWrite HDI_CLASSIC & MY_COMPUTER, 0 .RegWrite HDI_CLASSIC & MY_NETWORK_PLACES, 0 .RegWrite HDI_CLASSIC & MY_DOCUMENTS, 0 .RegWrite HDI_CLASSIC & INTERNET_EXPLORER, 0 .RegWrite HDI_NEW & MY_COMPUTER, 0 .RegWrite HDI_NEW & MY_NETWORK_PLACES, 0 .RegWrite HDI_NEW & MY_DOCUMENTS, 0 .RegWrite HDI_NEW & INTERNET_EXPLORER, 0 End With ' Create explorer command file to toggle desktop window Set oFSO = CreateObject("Scripting.FileSystemObject") sSCFFile= oFSO.BuildPath(oFSO.GetSpecialFolder(2), oFSO.GetTempName &".scf") With oFSO.CreateTextFile(sSCFFile, True) .WriteLine("[Shell]") .WriteLine("Command=2") .WriteLine("[Taskbar]") .WriteLine("Command=ToggleDesktop") .Close End With ' Toggle desktop and send F5 (refresh) With CreateObject("WScript.Shell") .Run """" & sSCFFile & """" WScript.Sleep 100 .Sendkeys "{F5}+{F10}in" WScript.Sleep 100 .Run """" & sSCFFile & """" End With ' Delete explorer command file oFSO.DeleteFile sSCFFile ' *** EOF ***