cluberti

885887: You cannot access network resources after you try to log on to a Windows XP Service Pack 2-based computer http://support.microsoft.com/default.aspx?...kb;EN-US;885887

Is the problem with pinging out to the 'net, or is it just an IE32 or IE64 problem?

Your stats lead me to believe that the spike is happening in kernel processor time (privileged), and you're seeing lots of paging operations per second which would indicate file cache access. Have you removed/disabled A/V on both the client?

- understood.

I agree with a good portion of your posts, if I don't necessarily agree with the products used. However, I know this list is for home users and average Joe's, so bravo for your ease-of-reading style and relative thoroughness. I do agree that using Windows Update should be #1 on the list, becuase having an up-to-date system regarding hotfixes and security releases usually makes all of the other problems less prevalent. Bravo to you for taking the time to write something up! I would like to add that I find it better, in the long run, for people to use a hardware firewall AND Windows firewall on their systems, rather than another software firewall. I know forcing a home user to learn how to use the hardware device is time-consuming (and oftentimes downright maddening), but it is ultimately better for the OS in the long run (if you're hitting the software firewall, you're already hitting a box that can be exploited). Multiple layers of security and all that. Overall, bravo.

If you have problems with both browsers, it's likely that the problem is external to those browsers and lower down the IP stack - perhaps A/V software, firewall software, NIC drivers, DNS issues, etc. Have you tried updating your NIC drivers, disabiling your firewall, bypassing your router, changing the DNS server(s) your machine is using, etc?

Did you make ANY changes to the system before rebooting and the problem occurring?

TB has an external disk - is it possible the video or your pagefile is on the external hard disk? That's the only logical conclusion I can come to for the "device" in question being listed as disconnected...

Well, thought I'd do some further digging for no apparent reason, and I came up with this - this may be why quicktime is causing your box to crash with a hardware error: Note that csrss.exe owns the quicktime.exe process. This could be an issue with quicktime making a call to an invalid hardware address, an invalid pagedpool or nonpaged pool memory address, or a request to a portion of the disk that is corrupt - since csrss.exe owns the process, it's likely that quicktime is bringing down csrss.exe when it crashes, causing the bugcheck. A reinstall of quicktime.exe to see if it still happens, perhaps? You can see that csrss.exe owns the quicktime process in the line "Owning Process 8646e020 Image: csrss.exe" in the dump information pasted in above.

OK, looked at your second dump uploaded - similar dump, same error, reported differently: Unless I'm in the twilight zone, this is a hardware error.

If you've got VPN links or routers with a ptp link between sites, as long as your machines on each domain know how to route packets from one site to the other, this should be possible using ADMT, USMT, and (if necessary) ExMerge. Create a trust between sites, and migrate users via ADMT, migrate their profiles via USMT, and migrate Exchange data via ExMerge. http://computerperformance.co.uk/w2k3/W2K3_ADMT.htm

Process explorer can show you what's actually running in the explorer.exe process.

Do you have antivirus software or antispyware software involved, or even backup software? Any piece of software that uses a filter driver is suspect.

I can't tell you exactly what, short of what the dump says - the status code c000009d translates to "STATUS_DEVICE_NOT_CONNECTED". That's all I can tell you - perhaps it's a chipset or disk controller driver issue, but when your machine is crashing, the OS is stating that the device being written to or read from has become disconnected, which almost always signifies a hardware error. Sorry I can't give you more, but the dump is pretty specific that I PM'ed you.

Well, this is why I never make assumptions from minidumps - they can be wrong . I didn't have to go any further than analyze -v to see what's wrong on your box. You've got a hard disk issue: 1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* KERNEL_STACK_INPAGE_ERROR (77) The requested page of kernel data could not be read in. Caused by bad block in paging file or disk controller error. In the case when the first arguments is 0 or 1, the stack signature in the kernel stack was not found. Again, bad hardware. An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or C000016AL (STATUS_DISK_OPERATION_FAILED) normally indicates the data could not be read from the disk due to a bad block. Upon reboot autocheck will run and attempt to map out the bad sector. If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging file is on a SCSI disk device, then the cabling and termination should be checked. See the knowledge base article on SCSI termination. Arguments: Arg1: c000009d, status code Arg2: c000009d, i/o status code Arg3: 00000000, page file number Arg4: 049a8000, offset into page file Debugging Details: ------------------ ERROR_CODE: (NTSTATUS) 0xc000009d - STATUS_DEVICE_NOT_CONNECTED DISK_HARDWARE_ERROR: There was error with disk hardware BUGCHECK_STR: 0x77_c000009d DEFAULT_BUCKET_ID: DRIVER_FAULT FOLLOWUP_NAME: ntmsd MODULE_NAME: hardware_disk IMAGE_NAME: hardware_disk DEBUG_FLR_IMAGE_TIMESTAMP: 0 STACK_COMMAND: kb FAILURE_BUCKET_ID: 0x77_c000009d BUCKET_ID: 0x77_c000009d INTERNAL_BUCKET_URL: http://deviceweb/Bucket/Bucket.aspx?BucketID=1543 OCA_CRASHES: 3077 (in last 90 days) Followup: ntmsd ---------

Does the issue occur if you boot up in safe mode?

Right - because Exchange is configured to use that DC for it's configuration data. You'll probably need to configure it to query the other two to make things redundant. I would recommend downloading and running the Exchange Best Practices Analyzer from the Microsoft site, as a start, and follow the instructions (well, most of the instructions ) given by the tool after it analyzes your environment. The RUS DC workaround is documented here: http://support.microsoft.com/?kbid=294792

I PM'ed, but I thought it'd be wise to post here as well. I was able to trace csrss.exe to what appears to be a driver, but the minidump doesn't contain any information about said driver. Do you perchance have a memory.dmp file in your \Windows directory that I can look at? That, assuming it's a kernel memory dump, should have at least the kernel information about the driver that belongs to the thread that dumped csrss.exe.

http://www.planetamd64.com/lofiversion/index.php/t11692.html You're going to have to "roll your own", as per the link above, because the perfection 610 is not going to get an x64 driver from Epson as per their own site documentation. Good luck.

The error you're getting is: 0x000000F4: CRITICAL_OBJECT_TERMINATION If any system object (file, process, thread, etc.) critical to system operation terminates with any unexpected error code (and csrss.exe is a very critical system object), Windows bugchecks with this (and possibly a few other) bugcheck messages. Is there any way you can post the dump file here, or at least the minidump file from the %windir%\minidump\ folder? I'd like to track the callstack back and see what kind of locks or traps I can find... Csrss.exe is likely the victim here, not the culprit, and so I need to see more than just an analyze -v statement to determine what's going on. Let me know if posting that dump from your XP box is a problem, and perhaps you can email or PM me.

Exchange is configured by default to look at one DC for a few things, and if that DC goes down you will have issues. There are ways around this, but I agree with fizban2 that we'd need to see some logs to determine more where the problem may lie.

Note that UPHClean really isn't meant for long-term use - it merely masks a problem driver or process holding the registry open, and it can cause corruption in (albeit rare) instances. You should use UPHClean to DETERMINE what is causing the registry to be held open, not as a fix in and of itself. That's why it logs what it had to kill to get the machine shut down - so you can fix it .

Two things - try giving a FULL path to the TRANSFORMS= file, and second, use qn rather than qb-.

You could also change RDP to listen on a different port (forwarding that new port from the firewall to your box) to see if that works - your ISP could be blocking 3389, or there could be packet size issues, etc.

You have to be very sure you followed the instructions for using an external time source correctly. I've used these instructions on many a 2K3 server without issue, so to recap: 1. Change Windows to use the NTP protocol for time synchronization: Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters Value: Type Data: NTP 2. Configure the AnnounceFlags value: Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config Value: AnnounceFlags Data: 5 3. Enable the NTP server value: Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient Value: Enabled Data: 1 4. Specify the NTP server to use: Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters Value: NtpServer Data: us.pool.ntp.org,0x1 5. Select the NTP polling interval: Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient Value: SpecialPollInterval Data: 900 6. Configure the time correction settings: Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config Value: MaxPosPhaseCorrection Radix: Decimal Data: 3600 Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config Value: MaxNegPhaseCorrection Radix: Decimal Data: 3600 After this, stopping and restarting the NTP service should get you working. If it does not, check the value configured in step 4 - this being misconfigured is the only time I've seen errors in the Windows Time service like the ones you've posted, so it's possible this is incorrect in your registry. I would also suggest using a time server OTHER than time.nist.gov, as it is a VERY busy time server and you are likely to miss one or two time syncs to it before you get a good one. I would suggest using another time server, preferrably a stratum-2 NTP server closer to you. You can find these listed here: http://www.eecis.ude...tp/clock2a.html