cluberti

Here's What You Need to Use Windows XP Professional • PC with 300 megahertz or higher processor clock speed recommended; 233 MHz minimum required (single or dual processor system);* Intel Pentium/Celeron family, or AMD K6/Athlon/Duron family, or compatible processor recommended • 128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported; may limit performance and some features) Yes, Windows XP runs like a dog on old hardware. It was released in 2001, when Intel's P4 was at 2GHz, AMD's AthlonXP was running the Palomino core at ~1.5GHz and 512MB of RAM wasn't unheard of (admittedly with 256MB being pretty standard fare on most people's new hardware purchases from the big-box boys). Install Windows 2000 or Windows 98 on the same hardware and yes, it runs much faster. They also do less security-wise, have fewer features (that you may or may not use), and XP's kernel does much more memory management and optimization cycles requiring a faster CPU to keep up (and let's be honest, even a 1.4GHz P4 is plenty capable of running stock XP at good speed). Ultimately, do what you'd like with the box - it's your machine, after all, and if you feel it runs better after being nLite'd or tweaked via services, go for it. I'm not here to tell anyone to change their ways, but to put out facts about what does and does not actually happen when you disable a service.

When did this start happening? Have you made any changes to the system before this occurred? I would strongly suggest using Process Explorer (from sysinternals) to take a look at CPU usage above and beyond what Task Manager is showing, so we can at least learn what process is utilizing the most CPU time. We can go from there, but we need that information over the course of a few hours. Also, have you considered running autoruns (from sysinternals as well) to disable all non-Microsoft startup items, services, and processes, and ShellExView (from nirsoft.net) to disable all non-Microsoft explorer.exe shell hooks? I'd do this and reboot to see if the problem continues as well.

If it's an x86 installation, the winnt.sif file goes into the \i386 directory on the source. If it's an x64 installation, it goes into the AMD64 installation directory on the source.

I've got an MSI board based on the same chipset, and I simply extracted everything from the downloaded files (via winrar) and pointed my install at the .inf's that were contained therein. The ATI chipset and video drivers are actually very easy to install unattended during setup, because they're basically .inf, .sys, and .dll files simply stored in the binary download along with the setup application (which is not needed). Simply extract everything using an archival program like Winzip or Winrar, and you should have everything you need.

You could always get another CD drive, and that's probably the easiest solution. However, if that's not an option, you can always attempt an installation over the network from another machine sharing the CD source, you could use PXE boot if you have a network server (RIS on W2K3 or a Linux server with the source), etc. You could even partition the drive you are installing to and put the source on a secondary partition, and boot to a boot floppy or CD to do the installation. Obviously another CD drive is the easiest way, but if you have another machine on your network, you do have options.

Well, I'm not sure where the information is being gathered by the Vista technician, but all versions of Windows Vista (including corproate VLK editions) will require activation with a licensing server, whether that be Microsoft's or an internal corproate server or set of servers.

I was actually going to post earlier that I thought it was Trend killing IE ungracefully, but I had to run for a bit. Now that I'm back, it looks like you've already discovered that. Have you considered downloading ad-aware, hijackthis and spybot via either Mozilla or IE, and attempting to use those before trying to use Trend again? You may also want to remove Trend completely, attempt to clean the PC properly via the other tools, then attempt to reinstall Trend to see if the problem recurs at that point? Also, msconfig or autoruns to disable all non-Microsoft startup items and services before attempting a cleaning is a useful step to take as well when you suspect a machine may not be clean.

To note, the memory dump files uploaded to Microsoft's Watson servers via WER are gone through via an automated process to gather stack and symbol data, so unless there's a real need (read: big problem needing more research), no human sees the actual dump data. I will have to concede that it's technically accurate that data about you could possibly be buried in the actual memory register addresses of a process dump if that data was being actively worked at the time of the dump, but that does no good in determining the problem - thread and stack data, plus CPU registers, are the important parts of a dump. It is important to remember and understand that Microsoft does provide mechanisms for you to continue to use WER without sending data from specific applications (or to use WER locally, and send nothing to Microsoft), and since WER is the wave of the future for error reporting (WER is deeply ingrained into Vista/Longhorn), turning it off is an option for those paranoid about personal data being on Microsoft servers. Just be aware that the WER is configurable, either to not send for specific applications or to not send at all (but still collect data locally - and optionally forward it to your own Watson server(s)).

That used to be the case (180 days), but will be no longer with all Vista versions (they've already implemented it with OEM versions of Windows XP SP2). Microsoft will keep track of licensed copies for the forseeable future once Vista RTMs - I'm sure it's possible that at some point the database will be relegated or retired, but that's likely to be the end of extended support (10 years after RTM) at least.

I think this has what you need: http://support.microsoft.com/kb/320982

By using the link below, and modifying it where necessary from Windows XP to Windows 2003, you should be able to copy the CD's files and make it bootable via the el-torito standard that the original CD your files came on should've been bootable as per Microsoft. It's not easy, but if you follow the guides carefully and modify as necessary, your CD should be bootable directly into Windows setup without the need for any formatting of partitions. http://www.nu2.nu/bootcd/wxp/

I have to chime in on this - usually I leave this one alone (along with the page file debates), but I just can't leave it alone (and I have absolutely no idea why ): Clipbook > A security risk to have your clipboard shown to whomever - It is possible to be a security risk on an unsecured/non-firewalled machine, but do be aware that f you disable this service you will not be able to use the Clipbook Viewer to see exactly whay you've got on your clipboard. Not a necessary service, but some people do use it (I personally do, as I do most of my day-to-day work using the clipboard). Distributed Link Tracking Service > Without a domain it's useless. - Possibly untrue - if you have NTFS formatted volumes on your local PC, this service is useful if you want the system to automatically track links (shortcuts) to files and folders. When a file that is linked to is moved, the DLTS modifies any shortcuts on the system to reflect the new location of the file or folder. Again, not necessary, but comes in handy for people who may have shortcuts to files or folders that may move frequently. See KB312403 if you want an overview of DLTS. Error Reporting Service > Great if you want YOUR computer reporting everything to MS - The sentiment in that statement seems a bit anti-Microsoft, but it is technically true that this service does send data to Microsoft about the error (almost always due to an application crash). Obviously no identifiable data is sent to Microsoft with the data gathered by WER (it's just a .cab file of the .dmp files dropped into a bucket matching other errors of the same or similar type and application), but I can understand people who feel this way about the OS sending data to Microsoft. There is an unintended side-effect, however, in that disabling the service disables all error reporting in the OS, so if an application crashes you will not be notified of the contents of the actual error by default, and in Windows Vista Dr. Watson's user front-end is completely gone, meaning you will have a harder time troubleshooting a failing or faulty application. Some people may need this, some may not. I'm guessing you don't, but the data sent to Microsoft is actually very good at helping determine when there's a big problem with an application or service, especially if it's a Microsoft app or service. Indexing Service > A resource hog that does nothing to speed access to anything - By default, no. However, if you configure the indexing service to index your files and folders, searches using the built-in OS search tools are much faster (as the search will scan the catalogs the indexing service keeps first, rather than searching the disk itself for files and folders, which is almost always much slower). This one is a trade-off between resources and functionality, and disabling it does provide some performance benefit in returned memory (if address space is mapped to RAM) in return for slower system searches. Internet Connection Firewall > A worthless POS. Zonealarm Free is 10x better. - It's better than nothing, but replacing it until Vista's two-way firewall is still probably a good idea for increased security (although 3rd party firewalls will take up at least as much resources as the built-in firewall). NT LM Security Support > Using telnet great, otherwise a waste. - There are a few reasons why this service might be required outside of a domain environment, but for most home users this service doesn't do them any good. Since it's only an interface to the kerberos and NTLM functionality of kernel security, disabling this service doesn't bring any noticeable performance benefits (the core OS security providers are still enabled, this is just a SSPI to NTLM for network communications where a provider is present). Performance Logs / Alerts > What average user even knows what this does, or cares. - Anyone who uses perfmon or WMI to gather performance-related data from a machine will need this service. It's best set to manual (the default), as it isn't loaded if not needed - disabling provides no benefit over manual due to the fact that the underlying performance libraries still load, run, and gather data, you are simply no longer able to gather data from those libraries.. If you do use WMI or perfmon to gather data from a performance library, it'll fail with this service disabled. Remote Access etc, etc > Again the average user won't use this. If you want to, your problem. - Anyone who uses PPTP or L2TP VPN tunnels using the Microsoft PPTP or L2TP providers (not a 3rd party IPSEC solution) will need this service. Again, the underlying providers still load, you just can't use them with the service disabled, so little benefit performance-wise to disable. Windows Time > Get a F**king watch. Turn this off. - If using Kerberos for any reason, do not disable this service as Kerberos relies on accurate system time (also domain users shouldn't disable this for the similar reasons in domain logon requirements). Otherwise, yes, but remember that the w32time binaries are only using resources when actually being called to sync time, so no performance benefit for most of the day to disable this. For the most part, I understand the views on these services. However, I have to second (or third, or fourth, whatever ) what most people are saying about supposed performance benefits in disabling these services - for the most part, there is none.

If you aren't using the boot manager to do the install, but running winnt, then you MUST have a FAT32 formatted drive that can be accessed from DOS to contain the temp files the installer will create. If you have not already created and formatted the partition you are attempting to install to, that's why you are getting the error.

It sounds like either a NIC or mass storage driver that the machine needs is missing. Assuming you've booted into RIS via PXE, can you install the original flat file image onto that PC as a test? If you still get errors there, then you'll likely have to integrate the proper NIC and disk drivers into the flat file that the riprep image was built from before it'll work properly.

It works just fine for the betas of 2007 - not sure if it'll change in the release version (I wouldn't be surprised if they change the check, but...).

Even though it's an ATI motherboard chipset, the audio chipset is a Realtek HD chipset, and ATI will not, at least as of this time, be releasing drivers for the audio chipset for Vista - they're leaving it up to the hardware vendors. You'll need to either use the realtek drivers from the link I provided, do without sound in Vista, or go back to a previous OS with supported, released drivers.

Each memory dump shows kernel pool memory corruption - that means it is possible that it's a hardware problem (which can be borne out by a memory tester), but it is likely it's a driver that is corrupting a kernel pool tag header if the memory hardware test passes. What happens in this scenario is that at some point in time while the system is running, a driver overruns or underruns it's allocation into another driver's allocation in the kernel nonpaged pool or kernel paged pool resource areas, causing pool memory corruption in that specific area of the kernel pool. When we come along later on to read or write to that corrupted area again by either the same driver or a different driver, we bugcheck with this STOP code. These are hard to track down without enabling special pool tagging in the kernel, and then we do need a kernel dump. Here's how to enable special pool and configure the server for a kernel memory dump: 1. Create or set the following registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management Value: PoolTag Type: REG_DWORD Data: * 2. Right-Click on the "My Computer" icon on the desktop and select "Properties"; this will open the "System Properties" window. Go to the "Advanced" tab and click "Performance Options". Click "Change" under "Virtual Memory". Set the pagefile to be located on the partition where the OS is installed, and set it to be equal to Physical RAM + 50 MB. 3. Also in the "System Properties" window, click on the "Advanced" tab, then click "Startup and Recovery". Make sure "Kernel Memory Dump" is selected. You can change the location of the memory dump file to a different local partition if you do not have enough room on the partition where the OS is installed. 4. You will need to reboot the server for these changes to take effect. The next time the issue occurs, you should then get a kernel memory dump that will contain "special pool tagging" data, allowing us to see what drivers make what pool allocations, and if an overrun or underrun occurs the driver itself can be pinpointed (note that this does not necessarily mean it's a hardware driver - anything using a file system filter driver, like A/V and antispyware software, can cause this as well). As long as it's not a bad index pointer from a driver causing this, a kernel memory dump with special pool enabled should tell us where the problem lies.

Exchange 2007 will run in a domain at Windows 2000 native, but is recommended to run in a domain that is at least at 2003 mixed-mode, and strongly suggested to run in a 2003 native AD. Exchange 2007 also requires that the Schema Master and the Global Catalog servers run Windows Server 2003 with SP1. Also remember that it the production RTM version of Exchange 2007 will be x64 only, so you'll need an x64 (Intel or AMD) Windows 2003 EE x64 machine for each install of Exchange 2007.

Oh yes, very possible indeed if the trojan can spread itself. I'd make sure you have a good, up-to-date, realtime antivirus scanner running on the DC before adding it to the network at all, let alone joining the domain and dcpromo'ing the box. Also, having all security updates installed before going forward is a good option as well.

The drivers here worked for me (not well, but worked). They leak a bit in audiodg.exe, so unless you think you'll be keeping your box up for days on end, it should be fine. However, the leak is drastic enough that daily reboots were necessary (audiodg.exe using upwards of 1GB of virtual address space, all mapped into physical RAM!). Hopefully their RTM drivers won't suck so bad, but it IS a Realtek driver, so it'll probably suck if history is any indication. http://www.realtek.com.tw/downloads/downlo...0Audio%20Codecs

If it is an Active Directory domain (either 2003 mixed-mode or 2003 native) and this isn't an SBS 2003 server, you can add a second DC, migrate the services over (DHCP, DNS, WINS if you're using it), configure the new DC as a GC server, transfer the FSMO roles to the new DC, and wait a few days for replication to complete. Once you're sure it's complete, run dcpromo on the old DC to remove it from the domain as a domain controller.

1 - Windows 2003 R2 was released for x86 (32bit) and x64 (64bit), but not Itanium (IA64). 2 - Windows 2003 Enterprise Edition and Datacenter Edition can utilize more than 4GB of RAM with the /PAE switch in the boot.ini file, as can Windows 2003 Enterprise Edition x64. Windows 2003 Standard Edition (32bit) cannot utilize more than 4GB of RAM. 3 - You will have to format the drive and reinstall the full version of the product, as the full product keys do not work on trial installs.

I'll take a quick peek at the minidumps later today, but with a STOP 0x1A, I might very well need at least a kernel memory dump, complete if you can swing it.

The web page for filemon should have all of the info you should need to get started. http://www.sysinternals.com/utilities/filemon.html

If you disable the Automatic restart option in the Advanced Startup and Recovery section of the System applet in the control panel, you should be able to see the STOP code and the memory data and module data related to the crash.