Laptop is Thinkpad T60. Several days ago it failed to load Windows in any mode and I started posting in the mup.sys thread, as that's where it crashed.
Today I thought my MBR might be corrupted, so...
I just put in a brand new HD and launched WinXPProSP3 from a genuine retail cd. The Windows CD loads up a bunch of drivers, then stops dead at the blue screen that says Windows Setup at the top and Setup Is Starting Windows in the white band at the bottom.
I'm guessing this level of basic disfunction means something but I'm not educated enough to know what. Can someone clue me in? Would be much appreciated.
It goes through POST fine and I looked at BIOS settings, nothing unusual and no errors.
I am still able to run UltimateBoot CD, which runs Linux. In fact after the crash I was able to get in the old hd with Linux and copy all my data files, nothing was corrupted.
Want to enjoy fewer advertisements and more features? Click here to become a Hardware Analysis registered user.
Just some background information into how weird debugging this kind of problem can get.
I know you said earlier it wasn't hardware, but that is still a possibility given all the information you've provided in the mup.sys thread and here.
Linux-based OS's and Windows-based OS's use different drivers and those do interact with the hardware differently. Thus, a Linux-based live CD could work fine while at the same time being unable to load Windows isn't an absolutely definitive diagnostic regarding hardware.
While you've tried a new HDD and the problem remained, it still could be for example a problem with the storage subsystem...e.g. the motherboard's HDD hardware interface circuitry that only comes into play when a Windows driver is used. The Linux-based diagnostic CD's for example, tend to try to use the lowest-common-denominator programming to maximize compatibility across multiple hardware platforms...thus they might not use some of the advanced HDD interface hardware that the Windows OS might try to use, and a problem thus could remain hidden using a Linux-based OS like that found on UBCD.
Similarly, it could be a different part of the motherboard that causes a problem only when using a Windows-specific driver function, e.g. the memory subsystem. Memory issues can cause unpredictable symptoms in any part of the system. For example, the OS uses parts of the memory and Linux and Windows use that memory differently (run-time modules, BIOS caching, video caching, disk I/O caching, etc). So a memory problem that affects Windows OS operations might not affect Linux OS operations at all.
Or, alternatively it could be even the PSU which has a problem which subsequently degrades the functionality of a hardware element on the laptop motherboard. It's all inter-related...and again is revealed only under Windows drivers.
If you can, another "easter-egg" you might try that is relatively cheap is to replace the memory module(s) with a cheap new or known good borrowed module. (I assume you've already tried reseating and swapping the existing modules and using them one at a time if you have more than one). If however, there is a core amount of built-in RAM on the motherboard, that's a part you can't replace easily and thus can't easter-egg. That "core" memory would also be the more likely memory to contribute to boot/OS-installation problems.
edit to add:
Another free and relatively easy to perform diagnostic is reduce the FSB clock (if possible) on the computer...perhaps 5% to 10% or so. This can reduce stress on the CPU, memory, and other bus-dependent circuitry. This can potentially reveal if any components have been degraded (e.g. via ESD or heat) and now unable to operate at previous frequencies or voltages.
John, thanks. I understand and agree with everything you said. I have indeed checked everything reasonably accessible. I have also performed several different memory tests, no issues found. I'm reasonably confident the power supply is OK, as I'm operating with a full battery and external supply both connected. I've also monitored all internal temperature sensors and fan, all show normal.
The BIOS (Phoenix First BIOS 79ETE0WW) setup menu does not offer an option for changing FSB speed. Is there another way to slow it down? The only CPU-related option is to allow multi-core processing (this is a dual core T2400 CPU). I will try forcing it into single-core and see if that changes anything.
Am I understanding correctly that there is no tool or systematic way of monitoring the Windows boot process to see what hangs it up? Am I stuck just changing things at random until it works? Sorta like a bad car mechanic?
John, thanks. I understand and agree with everything you said. I have indeed checked everything reasonably accessible. I have also performed several different memory tests, no issues found.....
One of the things I was trying to communicate is that the memory tests by anything that requires loading an OS, even a minimal OS, do NOT test all the memory, including some memory that would be used by Windows to manage system operations. A low segment of RAM is never tested...unless your system has no built-in RAM and you can swap memory modules (e.g. test with module A in slot0 and module B in slot1, and then move module B to slot0 and module A to slot1. That is the only way to test all the RAM in both modules as each is tested completely when in second slot (and each is tested only partially when installed in slot0).
If you have a block of non-removable RAM, then those diagnostics (like memtest86+) will never be able to test that block of RAM fully...no matter how long your run them.
The same it true if you only have 1 removable memory module and no non-removable RAM. You will never be able to thoroughly test all the RAM on that module on a given system.
The closest you can come to it is to make sure that BIOS/UEFI settings perform "long" memory tests at power-up. That will test all the RAM, including that low segment, but the power-on RAM tests are simplistic, don't last long, and won't catch all memory error types (e.g. pattern-related errors). Many systems default to "quick" or "short" power-up memory tests which are even less thorough. Your user manual should describe the settings.
Yes, thank you. Very good point. I swapped the 2 memory modules (one 2GB and one 0.5GB) and it still passes memtest86+ and several others on the UltimateBoot CD.
However, something else caught my eye, which I hadn't looked at before. Memtest reports as follows:
Intel core 1829MHz
Memory 2558M 2350MB/s
Chipset Intel i945GM/PM ECC disabled FSB 166MHz Type DDR2
Settings: 332MHz (DDR665)/CAS 5-5-5-15, dual channel Asymmetric
Seems to me FSB should be faster, although I hadn't looked at it before so can't compare. Does this look OK to you?
EDIT: Something else just occurred to me. So I likely have a hardware glitch or failure of some sort, ok. But also the "old" or "crashed" hd is now not visible to Windows when connected to another computer via usb. But visible just fine in Linux.
What are the odds of 2 failures occurring simultaneously? Zero. Unless related, which might be a clue.
memtest86+ has a long history of mis-identifying chipset, cpu, and timings info from various systems. For example, on this system, even high-level data like the Phenom 965 CPUID is reported as an Athlon 64 and DDR3 RAM reported as DDR1. Additionally, things like changing memory configuration between single-channel and dual-channel on the same motherboard can affect the timings reported (e.g. might report the right values in single-channel mode and wrong in dual-channel).
However, history also shows us that memtest86+ does an excellent job at finding and reporting memory errors up through the highest block of installed RAM, even while mis-reporting some hardware and settings information.
From my experience memtest86+ does not modify any settings or timings, so it tests at the timing and voltage parameters set by the user.
memtest86+ has a long history of mis-identifying chipset, cpu, and timings info from various systems. For example, on this system, even high-level data like the Phenom 965 CPUID is reported as an Athlon 64 and DDR3 RAM reported as DDR1....
Just reporting that MemTest86+ ver4.20 provided with UBCD ver5.2.2 is now showing CORRECT information for both my CPU and the memory and timings.
UBCD ver5.2.2 MD5=96c606bbdf9dba186e1ec36469eaf0df