cluberti

Actually, I think the error is valid - do you have a network trace of one client trying to connect to the other client's exchange mailbox? I'm betting you'll see network errors...

# for decimal 10064 / hex 0x2750 WSAEHOSTDOWN winerror.h # A socket operation failed because the destination host was # down.

As to the drivers, if the vendor doesn't have updated drivers, you're out of luck. However, if you aren't using the webcam, you could always simply remove it and uninstall any software for it. If you need one, perhaps using a different webcam from another vendor is probably a better option than sending the laptop back for repair (what are they gonna repair!?!? the driver is bad!!!).

Yes, you can still get security updates for another year and a half or so, and you can still pay for a support incident if you so choose.

How long is far longer lol:P a couple of seconds , minutes , hours? Hard to say, but probably tens of seconds, maybe a minute or so.

according to the minidumps, it certainly looks like you're having issues with this webcam driver suite (at least it looks like it's a webcam driver suite). Is it Vista certified? Doesn't look like it from the driver signature, but maybe the vendor has a version that is? // Looks like a 9f bugcheck, like you stated: 0: kd> .bugcheck Bugcheck code 0000009F Arguments 00000003 8d7596f0 8e1a5028 ab19ca30 // according to the help on a 9f, these mean: 00000003 == A device object has been blocking an Irp for too long a time 8d7596f0 == Physical Device Object of the stack 8e1a5028 == Functional Device Object of the stack ab19ca30 == The blocked IRP // So this is a blocking IRP timeout, the stack matches: 0: kd> kb ChildEBP RetAddr Args to Child 81f33acc 81e71b6c 0000009f 00000003 8d7596f0 nt!KeBugCheckEx+0x1e 81f33b28 81e716bc 81f33b94 81f33c50 81f4c401 nt!PopCheckIrpWatchdog+0x1ad 81f33b68 81ef4d00 81f4c4e0 00000000 b6981718 nt!PopCheckForIdleness+0x343 81f33c88 81ef4936 81f33cd0 a628d902 81f33cd8 nt!KiTimerListExpire+0x367 81f33ce8 81ef4483 00000000 00000000 0000b159 nt!KiTimerExpiration+0x2a0 81f33d50 81ef2f9d 00000000 0000000e 00000000 nt!KiRetireDpcList+0xba 81f33d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x49 // Tracked down the device object in the stack: 0: kd> !devobj ffffffff8e1a5028 f Device object (8e1a5028) is for: \Driver\SNP2UVC DriverObject 8e171a40 Current Irp 00000000 RefCount 0 Type 0000002f Flags 00002050 DevExt 8e1a50e0 DevObjExt 8e1a71f8 Device queue is not busy. // The driver object involved, looks like it's also relying on ks.sys and STREAM.sys, // so it's a kernel streaming driver of some sort: 0: kd> !drvobj ffffffff8e171a40 f Driver object (8e171a40) is for: \Driver\SNP2UVC Driver Extension List: (id , addr) Device Object list: 8e1a5028 DriverEntry: 909b5b85 snp2uvc DriverStartIo: 00000000 DriverUnload: 8d4d4599 ks AddDevice: 00000000 Dispatch routines: [00] IRP_MJ_CREATE 8d4cd0f4 ks+0x140f4 [01] IRP_MJ_CREATE_NAMED_PIPE 81e63fef nt!IopInvalidDeviceRequest [02] IRP_MJ_CLOSE 8d4c7265 ks+0xe265 [03] IRP_MJ_READ 81e63fef nt!IopInvalidDeviceRequest [04] IRP_MJ_WRITE 81e63fef nt!IopInvalidDeviceRequest [05] IRP_MJ_QUERY_INFORMATION 81e63fef nt!IopInvalidDeviceRequest [06] IRP_MJ_SET_INFORMATION 81e63fef nt!IopInvalidDeviceRequest [07] IRP_MJ_QUERY_EA 81e63fef nt!IopInvalidDeviceRequest [08] IRP_MJ_SET_EA 81e63fef nt!IopInvalidDeviceRequest [09] IRP_MJ_FLUSH_BUFFERS 909baf2a STREAM+0x1f2a [0a] IRP_MJ_QUERY_VOLUME_INFORMATION 81e63fef nt!IopInvalidDeviceRequest [0b] IRP_MJ_SET_VOLUME_INFORMATION 81e63fef nt!IopInvalidDeviceRequest [0c] IRP_MJ_DIRECTORY_CONTROL 81e63fef nt!IopInvalidDeviceRequest [0d] IRP_MJ_FILE_SYSTEM_CONTROL 81e63fef nt!IopInvalidDeviceRequest [0e] IRP_MJ_DEVICE_CONTROL 909baf2a STREAM+0x1f2a [0f] IRP_MJ_INTERNAL_DEVICE_CONTROL 81e63fef nt!IopInvalidDeviceRequest [10] IRP_MJ_SHUTDOWN 81e63fef nt!IopInvalidDeviceRequest [11] IRP_MJ_LOCK_CONTROL 81e63fef nt!IopInvalidDeviceRequest [12] IRP_MJ_CLEANUP 909bb1b2 STREAM+0x21b2 [13] IRP_MJ_CREATE_MAILSLOT 81e63fef nt!IopInvalidDeviceRequest [14] IRP_MJ_QUERY_SECURITY 81e63fef nt!IopInvalidDeviceRequest [15] IRP_MJ_SET_SECURITY 81e63fef nt!IopInvalidDeviceRequest [16] IRP_MJ_POWER 909bbcee STREAM+0x2cee [17] IRP_MJ_SYSTEM_CONTROL 909c02c0 STREAM+0x72c0 [18] IRP_MJ_DEVICE_CHANGE 81e63fef nt!IopInvalidDeviceRequest [19] IRP_MJ_QUERY_QUOTA 81e63fef nt!IopInvalidDeviceRequest [1a] IRP_MJ_SET_QUOTA 81e63fef nt!IopInvalidDeviceRequest [1b] IRP_MJ_PNP 909c0fd2 STREAM+0x7fd2 // The actual IRP blocking: 0: kd> !irp ab19ca30 Irp is active with 9 stacks 8 is current (= 0xab19cb9c) No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned cmd flg cl Device File Completion-Context [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 16, 0] 0 0 8d7596f0 00000000 909bb79a-00000000 \Driver\usbhub STREAM Args: 00000000 00000000 00000000 00000000 >[ 16, 2] 0 e1 8e1a5028 00000000 81e42db4-845b2120 Success Error Cancel pending \Driver\SNP2UVC nt!PopRequestCompletion Args: 00000000 00000001 00000001 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-845b2120 Args: 00000000 00000000 00000000 00000000 // Webcam, maybe?: 0: kd> lmvm snp2uvc start end module name 90812000 909b8280 snp2uvc T (no symbols) Loaded symbol image file: snp2uvc.sys Image path: \SystemRoot\system32\DRIVERS\snp2uvc.sys Image name: snp2uvc.sys Timestamp: Mon Jun 11 22:38:23 2007 (466E071F) CheckSum: 001AEC22 ImageSize: 001A6280 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 This could be related to the issue documented in 950127 as well, so you might want to apply that hotfix too. However, the root is likely the snp2uvc.sys driver. A quick google search for that driver also shows that you aren't the only one seeing this, and it's definitely this driver. Hopefully you don't have an Asus box .

Is the server service and the RPC service(s) running?

It'll probably run both about the same, although boot time with Win2K will take far longer on a 233MHz proc than with Win9x. However, day-to-day operation experience will likely be the same.

You can open the dump with windbg, from the debugging tools for windows package. If you can place the .dmp files (zipped or rar'ed) on a file download or FTP site, that would be good too.

My suggestion is to disable the spooler service, then restart. Once the box is back up, use the cleanspl.exe tool (from the W2K3 resource kit) to delete all of the print spooler's contents, minus the inbox processors like TCP/IP, LPD, etc. (you'll be prompted to delete these, please choose not to!). You may have to start the spooler service to do this, but I don't think it's required. After that, set the spooler service back to auto and reboot, and you should have a working (clean, but working) spooler. In the future, always make a spooler backup using the Printmig.exe tool before adding/updating a printer queue/driver, just in case situations like this arise. That way, you'll have a backup you can restore once cleanspl.exe is finished.

Amen. Took the weekend off, and look what happens .

Daemon tools installs SPTD, or the SCSI Pass Through filter Driver. All I/O on the system passes through ANY input/output filter drivers, regardless of whether they're used for that particular operation or not (this is also how most antivirus packages work, btw). So I don't know if it's a problem with nLite or SPTD, but it's definitely something you should investigate - perhaps upgrade SPTD.sys to the latest version, if you haven't already?

A driver tried to reference a NULL memory address (0x00000000). That will always cause a bugcheck, and if it happened when changing your IP address, I'd say anything on that machine is suspect. I'd remove your antivirus package and any firewall package, and also perhaps remove and update your network card drivers as well. You'll have to narrow this down the old fashioned way, because whatever is causing this is unloading and removing from the stack too quickly to catch unless a live debug is done, and we can't really do that in this case. Good luck.

If it was not repaired, you probably could have simply just used the last known good boot option. However, the repair has probably messed it up, and you're left with a reinstall as your option now. I'd say boot that machine with an ERD disc, get the data off, and rebuild.

I don't believe they're currently accepting bugs from anyone but TAP customers (and since it's in RC probably only showstoppers at this point to boot), but you can always try to file it anyway.

Let's remove the antagonism in some of the posting in this thread, or I'll close it. You know who you are.

It's the same kernel, but they are definitely not the same (tuning and features installed) out of the box.

You need to set the symbol path - I prefer the _NT_SYMBOL_PATH System environment variable for this, and set it to SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols.As to the dump, it's the same (different address, but same result - nothing there at all). Please disable DEP via boot.ini before posting any more dumps.

Sounds like you should install the hotfix in KB934611, because you've got a non-Vista compatible TDI driver or network driver installed causing this. It's probably got a TDxDeviceLock and isn't releasing it properly, causing the next IO request over the TDI subsystem to crash. Since this is specifically not allowed to happen, the machine is doing what it is supposed to and is letting you know you've got a faulty network or TDI driver (it could be your antivirus package's TDI filter driver, btw - it doesn't always mean it's your actual network card driver).

What version of the RDP client are you running, and what OS is the server? Also, does mstsc /admin work at all?

Happy bday geek. One year older and all that .

Well, I can't speak to your rant, but I can tell you that there is a Windows Update client in Vista. Doesn't help you, and I don't think what you're asking is possible with the current codebase in XP/2003 or 2000. As to why not give the option, have you ever heard of the United States Department Of Justice (DOJ)? Microsoft has to do this because of them, directly.

I don't know, honestly. I'm running Vista, and I haven't ever tried to hack in 5.x versions of .dll files on Win98. I have no experience in this, although we probably do have people in the Win9x forums that do.

Hmmmmm... Is it just the 2003 server, or can you repro this in a Vista or XP VM as well?

If that's the case, the entirety of what's left to touch is within the driver. If the beta doesn't help, I'm not sure what else could be done other than re-writing the driver.