Mr Snrub

I'm not sure there is anything you can do about that - the BIOS presents the devices to the OS and they are enumerated in the order they appear. Is this causing a problem, though? The order/number of the drives in XP should not matter... If the system is trying to boot off the wrong disk, that should be configured in the BIOS too.

Aha, took a couple of goes but I see what you mean now - it didn't seem to repro reliably with files named test1, test2, test3 at first, but after changing them to "a document", "because i can", "care to test and "donuts" (a,b,c,d) I can get the same effect. It happens in any folder view, not specifically the desktop . the cut selection is correct, however, it is just a display bug.

So it isn't blitzing the setting for the wallpaper or overriding it with a GPO, and if Explorer is killed the wallpaper reappears (or more correctly, the strange grey sheet in front of it is removed).As soon as explorer.exe is relaunched, the grey screen returns? Happens at all resolutions and colour depths? Happens for all users who log on? Changing the wallpaper has no effect? What colour is the desktop set to, when no wallpaper is in use? Take a hang mode ADPlus dump of explorer.exe and upload it somewhere, I can take a look if there is anything quirky going on in the running threads (but it may be something that has "been and gone"). http://www.microsoft.com/whdc/devtools/deb...ng/default.mspx ADPlus command line (ideally run after killing & relaunching explorer.exe without opening anything else): adplus -hang -ctcf -pn explorer.exe -o c:\dumps

The MMC is a generic console that uses .MSC files to remember views.A lot of the administrative tools used in Windows are just shortcuts to .MSC files, so when clicked they open MMC and bring a standard layout up depending on which component they are meant to adminster. Click Start, then Run. Type mmc, then press enter - this will launch a blank Microsoft Management Console window. Click File, then Add/Remove Snap-in. Scroll down the list of available snap-ins on the left, double-click Services, then click Finish, then OK. Arrange your panes as you like, then click File, then Save. Browse to a convenient location to save your shortcut and give it a meaningful name*, then click Save. Now close your MMC window and double-click on the file you saved - it should re-open the same view you just had. * A convenient location on XP might be C:\Documents and Settings\(your username)\Start Menu, and a meaningful name something like Services MMC.

Hmm, I've not seen that symptom since before beta 2 - I ran into it myself and found no partitions or letting Vista create the partition during install made it fail on the first boot. The workaround I used was to hit shift-F10 to bring up a command prompt window before setup reached the disk/partition selection screen, then use diskpart to create the partition and format it, then exit the command prompt and continue setup. The problem was specific to my A8N-SLI Premium, the other systems didn't have that problem, even using RAID0'd Raptors. By RTM the in-box drivers Asus gave MS resolved the issue without the workaround.

SATA (or SATA 2) disk I assume? And it's just a single disk, no RAID setup? I don't know how many SATA controllers & ports that mobo has, but have you tried swapping? I would forget AHCI, stick with regular IDE emulation mode. Is the media SP1?

You mean the difference in the fast & slow network segments are not logical, but physical?What are the switches involved in the good & bad scenarios, using the same client & server to test? ICMP round-trip time might test fine, maybe even UDP, but SMB communication is over TCP so a pure ping test to measure latency is not so useful. How does RDP work to the server from the client, compared between the 2 segments? Have you tried forcing the duplex & speed of the NIC on the client to different settings and compare the results in the bad segment? Network traces are still useful even where routers are not involved - it would be interesting to take a look at a simultaneous network trace from a Vista client and the W2K3 server being accessed, then compare with simultaneous traces from the same server and an XP client doing exactly the same test. A typical test routine would be: If you want to do that test on the Vista client and then the XP client and share the capture files I'd be happy to take a look to see if we can figure out what is going on. (The pings are for marking the trace so it is obvious when the results came in, and the sizes are to distinguish from any other ICMP traffic the client may generate.)

Great news As a side note, this is a handy feature of Vista - Windows Error Reporting (WER) would have checked the OCA for you and presented you with the solution automatically, and it shows the value of the "report this problem to Microsoft anonymously" messages.

Okay, so that proves it's not a display bug - if ESC hadn't "un-greyed" the icon but F5 (refresh) did, then I would have said it was some quirk in Explorer. Some Explorer extension is, under some unknown circumstances, sending a pseudo key sequence for CTRL-X or similar for random selected objects - very tricky to track down through debugging (without a simple repro) so that would be best approached through removing software (or clean install) and trial & error. Teracopy, by its description and purpose, does seem like the most likely candidate.

http://www.microsoft.com/presspass/feature...6-26hyperv.mspx http://www.microsoft.com/windowsserver2008...solidation.aspx

Both dumps are STOP 0xA: IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. First dump has no stack, so not much of use, however the debugger reports the exeception caused by a driver calling nt!IoDetachDevice. Second dump is better: Crash occurred because EAX was 0, and the module sonpvl3.dll was the originator of the nt!IoDetachDevice call: However, in this instance the debugger even manages to provide an OCA link for this issue: http://oca.microsoft.com/resredir.aspx?sid=5404&State=1

Attach to your process using Windbg. Click Debug / Event Filters. Select the 6th entry in the list "Unload module", click the radio button "Enabled". Click Close, then enter "g" to let the debuggee resume. Debugger will now break in whenever a module unloads.

Is it a hologrammed CD, or one you have customized & burnt yourself? If it is a custom CD, have you tried a clean install to see if it can update without problems?

What happens if you click Start / Run and enter "mmc" to launch the console without any snapins? If it loads okay, test the following: 1. click File / Add or Remove Snap-in 2. in the left pane, double click "Computer Management" and click Finish 3. click OK

You are welcome, and the answer is "both" Though I'm not half as good as some of the guys that work here.

Okay, you did the hard work The hook points to the module which is always missing when explorer calls into the msgina function, which in turn leads to the crash - the module is therefore unloading (without a trace) but also without unhooking itself first - bad. With the breakpoint on the attempt to write to the IsDebuggerPresent, rather than use "g" to continue it is simpler to look at the threads to see which was doing the write: The 1-byte write operation we were watching for has taken place, we replaced 0x64 with 0xe9: Looking through the list of threads it was easy to spot the one which has the module you already hinted at (24): Looking at the second frame's return address we can see what address it started at in frame 1: Now we can unassemble from this function entry point and see what it does: There is the "put byte value 0xe9 into address pointed to by register ECX" instruction, where ECX was set up to point to the IsDebuggerPresent function. The entire function just seems to replace a single byte at a time, so must be called 6 times to place the hook - I assume this is to avoid detection by containing the offset as a string of bytes, this is all of it: So this isn't by mistake, the module is most definitely doing a deliberate hook in a manner that is trying to avoid detection, for what reason I couldn't say. Take a look at the top few frames of the call stack again: When explorer.exe does not crash, this module is still loaded and so the IsDebuggerPresent hook can jump into this module without causing an exception - if it has been unloaded then it goes boom, and that's the only reason we spot this dodgy behaviour.

Try this then, we can monitor just a single byte in the 6-byte range: ba w1 kernel32!IsDebuggerPresent (I suspect the w4 makes it have to be dword-aligned, so only addresses 7c813128, 7c813124, 7c813120 would work.)

Try: ba w4 7c813122 The address is not word-aligned (ends in an odd number) so maybe that will help...

Hmm, if you have symbols configured then the label should be translated to an address for you... What does it return if you enter: x kernel32!IsDebuggerPresent That 'x' command should return the address we want to set the breakpoint at, e.g. on my 64-bit W2K8 server it gives: It is the "ba w4" command you want, even though 6 bytes are being patched we can catch a change to any of the first 4 and keep it dword-aligned if that's what is making the debugger unhappy.

Summary of the crash, same as before: Compare that with the non-crashing scenario: So explorer.exe is starting to dim the desktop and msgina.dll makes a call to check if a debugger is attached, this function has been hooked at points to a bogus address, so boom (and reload). The reloaded version has not had a reason to load the hooking module yet, so now Start / Shut Down has no problem. I don't like the presence of that module from 1999, we could try renaming the file on disk to make it impossible to load, but there are a few other modules that weren't loaded in the "okay scenario" too: We can be smarter in our investigation, however... Reboot the client and logon, then launch windbg.exe and attach to the process explorer.exe, then enter the following commands in the debugger: .symfix+ c:\symbols !sym noisy .reload /f ba w4 kernel32!IsDebuggerPresent g A breakdown of the commands so you know what they are doing: ".symfix+ c:\symbols" sets up the local symbols cache path and public URL for the symbols server (you don't need this if you have the environment variable _NT_SYMBOL_PATH set) "!sym noisy" - turns on verbose information when loading symbols, so you get some feedback rather than a flashing cursor ".reload /f" - force a reload of the symbols for all modules (rather than get them when they are needed, saves time later) "bw w6 kernel32!IsDebuggerPresent" - sets a breakpoint on the IsDebuggerPresent function when something writes to it "g" - let the debuggee (explorer.exe) resume Now play with Windows, run various apps, etc. until explorer.exe hangs - you will find the debugger has broken in when something has hooked the function and we can see what it is, if you enter the following command: .dump /maf c:\explorer.dmp This will create a full dump of the process - let us have a look at that dump and what the last thing you did was before the hang. Once the dump is written you can enter "g" again to resume the process to un-hang Explorer.

When talking about partitions you need to forget drive letters and look at 2 main things: 1. which is the active (system) partition your system started from 2. which is the (boot) partition the current instance of Windows is installed on In your case, you have 3 partitions: Partition 0 = system partition, and boot partition for Windows XP Partition 1 = data partition Partition 2 = boot partition for Windows 2008 When the computer starts, the BIOS locates the active partition from which to load the boot manager, then the boot loader is selected (interactively, as you have 2 boot loader entries). The boot loader points to the partition where Windows is installed and the main part of the boot process takes place. In the case of selecting XP, everything happens on the first partition so the drive letters are Partition 0 = C: (system, boot) Partition 1 = D: Partition 2 = E: In the case of selecting W2K8, the boot process starts on partition 0 and resumes on the boot partition 2, so the following is the enumeration order: Partition 2 = C: (boot) Partition 0 = D: (system) Partition 1 = E: (As fizban2 pointed out, regardless of the target partition for which Windows will be installed, it will be C: by default - AFAIK you can't change this through a regular setup and it can only be defined to another letter through a scripted installation.) When booted into Windows, you cannot change the drive letter of either the system or boot partitions (this has always been the case), which is why when booted into W2K8 you can't reassign C: or D:.

In Safe Mode, use MSINFO32.EXE and save a report then attach it here. Are you using a PS/2 keyboard? If you are, then we can set up the manual memory dump option and crash Windows when it is booted normally and stuck at the wallpaper screen to see what the processes/threads/drivers/services are doing.

Not heard of TeraCopy before, but from the wording on their site I would say yes: http://www.codesector.com/teracopy.php Mind you, I wouldn't ever use a tool that the author knows is not DEP-friendly, and their recommendation is to disable it! http://help.codesector.com/TeraCopyFAQ

So the system starts up okay in Safe Mode? I have seen this kind of behaviour on a client which had 2 AV products installed at the same time, and their services did not play well together, they deadlocked each other... did you change or install any security product just before the problem started?

Hmm, given what you have described and the explorer dump we have already seen, it sounds like a module that msgina.dll is supposed to call into has been unloaded "sometimes" when it comes to dim the screen when presenting the shutdown/restart/sleep options... Without resorting to time travel debugging, what we need are 3 dumps: - ADPlus hang mode dump of explorer before Start / Shut Down is clicked and the error does NOT occur - ADPlus hang mode dump of explorer before Start / Shut Down is clicked and the error DOES occur - ADPlus crash mode dump of explorer when it has the error 1. Make sure no applications or Explorer windows are running. 2. Open a command prompt and enter the commands: cd \progr* cd debug* (This should put you at the "C:\Program Files\Debugging Tools for Windows (x86)" prompt.) 3. Then enter this command: adplus -hang -ctcf -o c:\dumps -pn explorer.exe (This should produce a hang-mode dump of all explorer.exe processes and put them into a unique folder in c:\dumps, wait for the procedure to complete.) 4. Now enter the command: adplus -crash -ctcf -o c:\dumps -pn explorer.exe (Now there is a debugger attached to explorer.exe and it will generate a dump if the process raises an exception.) Following this command, click Start / Shut Down: - if the process does not crash, hit ESC on the dimmed window and rename the hang mode dump folder from step 3 to "Hang1NoCrash" - if the process does crash we should get a crash mode dump created and now there are 2 folders in c:\dumps - rename the first to "Hang1Crash" and "Crash" Repeat the procedure until you have hang mode dumps of the process when it did and did not crash, and the crash dump. By observing the difference in the 2 hang mode dumps, and the address of the exception in the crash dump, we may be able to figure out what is going on.