cluberti

wow - if it only works on Windows, why write it in a portable language... It's not like Windows is going to up and go PPC with a linux core anytime soon. I think I've seen it all, at least until I see something else this stupid

I have to disagree with your action plan there,prithvi - one problem and you reformat? I can see if your machine gets infected with a virus, or you have severe security or registry problems, but in my opinion a solvable problem like system slowness or HDD thrashing (or both) doesn't warrant a reformat, ever. And with regards to the actual problem originally posted, if it was a fragmentation or disk full issue (as you touch on in the beginning of your post), he'd get the error when doing a File > Save or browsing the drive itself, which the original poster has stated he does not. This is definitely not a drive full or fragmentation issue, and should not be troubleshot as such. That's just wasting time (as is reinstalling the whole OS and applications as well, with no guarantee that the problem will not return - THEN what?).

I'd actually like to address some of Mr. Thurrott's points here, if I may, regarding x64 Vista: That's true, but there are very few installers (most are old wise-based installers, too) for 32bit apps that are 16bit. Also, running 16bit code on an x64 processor is impossible, due to the lack of hardware support for 16bit execution - and emulation is frankly out of the question, as Microsoft has been trying to quash 16bit code since Win95. Let's move into the late 90's here. In a sense, it's true - old hardware likely won't work in Vista (mostly old peripherals and old multimedia cards, audio and video). But especially for the old stuff, if it was made over seven years ago, or was designed for Windows 98, don't expect it to work in Vista. Vista is 3 releases from Win98. This all boils down to hardware and drivers - make sure you get x64 compatible hardware, and it's really not a problem. I don't see this as a problem for new purchases, but upgrades obviously might require some tweaking (which folks rightly might not want to fork out $$$ for). Again, if it doesn't require a 32bit filter driver or insecure DCOM permissions, it's very likely going to work (x64 hardware can still run 32bit code natively, and it's still the Windows kernel running underneath). The filter driver issue is addressed in those applications by releasing x64 versions (antivirus, antispyware, backup software, CD burning software perhaps, etc). Again, I've not run across any application that doesn't run on Vista x64 under WOW properly, but I'm sure they're out there. The pool of apps that just "won't work" is going to be smaller than those that do, and you can always download the Application Compatibility toolkit and get your app to work if possible before givign up. Isn't that obvious? You can't mix and match, it's either all or nothing. "Upgrading" 32bit to 64bit would be a complete reinstallation anyway, considering ALL of the binaries on x64 are different than their 32bit cousins (both architecturally and, in some cases, location-wise). See above - they aren't the same, and they can't be treated as such. If these are his issues, that really isn't a long list of complications, as he calls it. Again, if your hardware has drivers, and you've got x64 versions of your antivirus (and antispyware) software, you should be able to run x64 without issue. If you don't, you'll have to change some things, and that could put people off. But don't discount x64 before you at least research it. I know crahak has some good reasons for not using x64 from previous posts, but everyone should at least consider it before making a decision.

Well, I can see that there aren't native x64 apps, but I've yet to run across one (other than antivirus/antispyware or requires special DCOM permissions : read insecure) that doesn't run just fine on x64. Also, the WOW64 layer does provide an environment for x86 apps to run on the 64bit OS, but if you're using x64 (not Itanic) the software isn't running in an emulated environment, it's running native 32bit on the x64 hardware, so no speed hits there or anything of that nature. Also, if you're running an x86 application that was compiled as large address space aware, you get 4GB of usermode process space rather than 2GB on x86, so that's a benefit as well. Drivers are the big sticking point, to be sure, but for most of us, I would doubt that applications would be.

You can't do that from an answer file directly, you'll need to boot your image to WinPE first, use diskpart to create partitions as necessary, and then kick off Windows setup.

If you have an application that is hanging or crashing, or a system that is misbehaving due to hangs, high CPU, severe slowness, etc, you may be asked to create a memory dump - perhaps of the application that is believed to be having issues, or of the entire system if the computer is misbehaving (or of both an application and the whole system!). This post is meant as an instruction manual on how to gather data if you are going to post for help on resolving one of these types of problems. The first thing to do, before doing ANYTHING else, is to download and install the "Debugging Tools for Windows" for your Windows platform: - x86 version. - x64 or Itanium (64bit) Once you've installed the tools, here are instructions on how to create the appropriate dump if you are so asked: Memory dump from an application/process that is HANGING (not crashing): 1. Create a directory called c:\adplus 2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 3. Type the following command in the command prompt: cscript adplus.vbs -hang -pn appname -quiet -o c:\adplus (where "appname" is the .exe name of the application that is hanging) 4. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed. Memory dump from an application/process that is CRASHING (not hanging): 1. Create a directory called c:\adplus 2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 3. Type the following command in the command prompt: cscript adplus.vbs -crash -pn appname -quiet -o c:\adplus (where "appname" is the .exe name of the application that is crashing) 4. Once the application you have attached to in step 3 eventually crashes, the debugger will create a .dmp file (or files) of the process. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed. Memory dump of the entire system: 1. Create or set the following registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters Value: CrashOnCtrlScroll Type: REG_DWORD Data: 1 2. Right-Click on the "My Computer" icon on the desktop and select "Properties", then click the "Advanced tab. On the "Advanced" tab, click "Settings" under the "Performance" header. Click the "Advanced" tab, then 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 on the "Advanced" tab, click the "Settings" buttun under the "Startup and Recovery" header. Make sure "Complete Memory Dump" is selected (see 3a if this is not in the list). 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. 3a. If the "Complete Memory Dump" option in step 3 is not available, you will need to manually set this registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 4. You will need to reboot for these changes to take effect. 5. The next time that the system is exhibiting the problem you were asked to dump the machine for, hold down the RIGHT CTRL key and press the SCROLL LOCK key twice to cause the machine to bugcheck and create a memory dump. After the box comes back up, you'll find the resulting memory dump file in %systemroot%\memory.dmp that can be analyzed.

Use the "Active Directory Users and Computers" snapin on one of the DC machines (or the DC, if you have only one server). Change the password for the built-in "Administrator" account - but as has been previously stated, you should always have at least 2 admin accounts. Create another account with the same privilege level as the Administrator account if you have not done so already

Are the updates listed in add/remove programs as installed, and do the kb******.log files for each hotfix show installation successful, or something else?

Good luck, and let me know how it goes. If you need any help, just post here or PM.

You'll have to run regedit and check permissions on that key - sounds like the administrators group either doesn't have access to that key specifically, or your account has been denied. If you run regedit you can check the permissions on that key (and any key above it in the chain) to make sure you really do have access.

lol

If you're at the "Welcome" screen, does the display turn off after a time (30 minutes or less), or does it also stay on?

First, you didn't answer my question - does it happen in safe mode? If it does, it could be a hardware issue. If it doesn't, it's a driver or software issue that can be troubleshot somewhat easily. So I ask again - does it happen in safe mode? After you have tried safe mode, assuming it doesn't happen then, you can gather a complete memory dump from the box while it's hanging like that and I can likely tell you where the problem lies (this requires a PS/2 keyboard attached): 1. Create or set the following registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters Value: CrashOnCtrlScroll Type: REG_DWORD Data: 1 2. Right-Click on the "My Computer" icon on the desktop and select "Properties", then click the "Advanced system settings" option in the left-hand pane of the window. On the "Advanced" tab, click "Settings" under the "Performance:" header. Click the "Advanced" tab, then 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 on the "Advanced" tab, click the "Settings" buttun under the "Startup and Recovery" header. Make sure "Complete Memory Dump" is selected (see 3a if this is not in the list). 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. 3a. If the "Complete Memory Dump" option in step 3 is not available, you will need to manually set this registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 4. You will need to reboot for these changes to take effect. 5. The next time that the system appears to be hanging like you have stated, hold down the RIGHT CTRL key and press the SCROLL LOCK key twice to cause the machine to bugcheck and create a memory dump. After the box comes back up, you'll find the resulting memory dump file in %systemroot%\memory.dmp.

Nitroshift is correct - upload it somewhere (or PM me and I'll provide you an upload location) so it can be reviewed with windbg (part of the debugging tools for windows).

It depends on what you're going to do with it, and what you're going to run on it. I've been running x64 versions of Windows for quite some time now, back to the x64 XP betas, and currently run Vista x64 RTM on my own boxes. It's great and I've got no program or driver compatibility issues, but you do need to check that before you jump in. Also, I do find x64 faster for most tasks than x86, but again, driver support (and the quality of those drivers) does affect x64 performance immensely - if you've got good driver support and your apps run, I'd say go with x64 (make sure you've got at least 2GB of RAM for Vista though, as x64 generally requires more memory due to more registers and address space used by applications than x96).

Check your PM.

If you really are getting to the point where the HDD activity is slowing your system to a complete crawl, you can gather a complete memory dump from the box while it's hanging and I can likely tell you where the problem lies (this requires a PS/2 keyboard attached): 1. Create or set the following registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters Value: CrashOnCtrlScroll Type: REG_DWORD Data: 1 2. Right-Click on the "My Computer" icon on the desktop and select "Properties", then click the "Advanced system settings" option in the left-hand pane of the window. On the "Advanced" tab, click "Settings" under the "Performance:" header. Click the "Advanced" tab, then 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 on the "Advanced" tab, click the "Settings" buttun under the "Startup and Recovery" header. Make sure "Complete Memory Dump" is selected (see 3a if this is not in the list). 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. 3a. If the "Complete Memory Dump" option in step 3 is not available, you will need to manually set this registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 4. You will need to reboot for these changes to take effect. 5. The next time that the system is incredibly slow or even appears to be hanging due to the HDD activity, hold down the RIGHT CTRL key and press the SCROLL LOCK key twice to cause the machine to bugcheck and create a memory dump. After the box comes back up, you'll find the resulting memory dump file in %systemroot%\memory.dmp.

Do you get the same problem in safe mode?

You don't - you have to do it manually via commands from the command line to replace files, as the link in the previous post describes. There is no sfc from the command line recovery console.

Haven't experienced that problem either - perhaps clearing your browser's cache and cookies, and making sure you have at least 10MB of space for cache might help you?

Try putting the driver .sys files in i386\SYSTEM32\DRIVERS as well, and the .inf files in i386\INF too, then restart the binlsvc and see if that helps - I've seen that work with 8110 Realtek NICs, and the 81xx drivers appear to be unified (just tried it on an 8139 in an XP image and it worked), so it might work for you with the 8169.

It's not a bug, it was functionality removed because IE7 no longer needed the reboot and the runonceex functionality to install correctly. The functionality may be added back, but it's not a bug. It was removed on purpose.

This happens to you regularly on Windows 2000 installations? What IDE or SCSI controller are you using, and have you added any disks or partitions recently?

Perhaps the error message isn't bogus? Perhaps the app doesn't get the data it expects from the URL, and thus gives that error? Seems odd that the app is giving an error about a URL - that usually means the data posted to the URL didn't give the app what it expected - not sure what to say about that, other than to ask what the application writer/vendor has said in response to that question after it was asked of him/her/them?

That registry hack was disabled by the RC2 build - it will not work on RTM, as I've already stated.