cluberti

Setting it as a Machine Startup script in computer policy (gpedit.msc) is as soon as you're going to run this, unless you wish to do some research into how to run a command at boot time (like as seen with defragmenter program's boot time defrag, or pagedefrag from sysinternals).

First thing to do is check the BIOS clock - if it's not at least mostly accurate, it will cause skew. Second, I would suggest using a less busy time server, like one from pool.ntp.org. Also, consider the net time /setsntp command to set (not the UI): net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org" You can also use the UI to change the time source, for example using 2.pool.ntp.org (make sure to update time before clicking "OK"). If you're sure the BIOS time is correct, and you're using a non-NIST or non-Windows.com time service, and it still skews, perhaps it can be tracked down via debugging the time service (it is possible).

See, now you're assuming the version of the spooler is at issue, when we have no data backing this up, and installing older versions usually isn't possible without hackery (which I'd suggest you avoid). It might be best to start the spooler, and then gather a crash dump of spoolsv.exe when trying to install the driver to see what is actually happening.

When you get a network trace of the traffic from W2K8 -> Vista vs Linux -> Vista, are the connect packets and other traffic sending the same? It sounds like the Linux box might be doing something or sending something in the headers that the Vista box doesn't necessarily like or maybe expect?

You are correct, this does appear to be something Vista supports. If it's not working, I'd consider using GetLastError to see what the return value was (check for NULL, as that is the return if it fails).

First, I can't really answer that first question without posting pages and pages of debug notes. It involves an intimate knowledge of wininet, which I have. Second, the value for MaxConnectionsPerServer isn't 1, it's 2 (MaxConnectionsPer1_0Server is 4) - and your system has 2 according to the wininet globals in the dump you provided, but only was using 1 connection (again, wininet innards). You could try upping the MaxConnectionsPerServer to something larger, like 6 (IE8's default) to see if it helps, but I don't see a real indication this is your problem.

That's not completely true. It 2 devices per channel, 2 channels per controller. Depending on the controller setup, there may be more then one SATA controller, also, IIRC even in IDE emulation mode, I believe most chipsets emulate more then one controller to allow all SATA ports to be used in IDE mode. Most of the time, the SATA ports are split up over two controllers as well. That is true, but this being an 865 chipset, the IDE and SATA come off the same ICH5 controller and supports up to 4 IDE devices (emulated or otherwise). Only when the SATA ports are in SATA mode will you be able to get 6 devices onto a mobo with this chipset unless the vendor added a separate controller, which Intel did not with this board - therefore, I think this may actually be what is happening, and not a PSU problem. Intel® 865PE Chipset - Supports FSB 800/533/400MHz - Supports AGP 8X interface - Supports DDR 400/333/266 memory interface Intel® ICH5 Chipset - Hi-Speed USB (USB2.0) controller, 480Mb/sec, 8 ports - 2 Serial ATA/150 ports - 2 channel Ultra ATA 100 bus Master IDE controller - PCI Master v2.3, I/O APIC - Supports both ACPI and legacy APM power management

Also, if the SATA drives are in IDE Emulation, you can not have any more than 4 IDE devices in a PC at any one time (only 2 channels, 4 devices).

Is this only a Vista problem, or can you repro it on a stock XP SP3 install, say? Also, are you sure you have no firewalls or antivirus sitting as LSPs on the network stack that would slow the traffic down? If LRPC works immediately, then RPC is working fine, and something on the network layer is responsible for the delay (but what that could be, hard to say right now).

So the spooler service isn't running when you try to install the driver? Are there any events in the System or Application event logs showing why the spooler service fails to stay running?

Is this the driver installer you are using?

// The worker thread to spin up a new window: 0:010> ~61kb ChildEBP RetAddr Args to Child 107aff6c 7c92da2c 7c93026d 00000410 107affac ntdll!KiFastSystemCallRet 107aff70 7c93026d 00000410 107affac 107affb0 ntdll!NtRemoveIoCompletion+0xc 107affb4 7c80b713 00000000 00000002 096ee994 ntdll!RtlpWorkerThread+0x3d 107affec 00000000 7c930230 00000000 00000000 kernel32!BaseThreadStart+0x37 // The OLE call to start the RPC thread: 0:010> ~60kb ChildEBP RetAddr Args to Child 1676ff1c 7c92d1fc 7c8023f1 00000000 1676ff50 ntdll!KiFastSystemCallRet 1676ff20 7c8023f1 00000000 1676ff50 7c802550 ntdll!NtDelayExecution+0xc 1676ff78 7c802455 0000ea60 00000000 1676ffb4 kernel32!SleepEx+0x61 1676ff88 769ae32f 0000ea60 0d3f6c40 769ae3ee kernel32!Sleep+0xf 1676ff94 769ae3ee 00000000 044efa18 0d3f6c40 ole32!CROIDTable::WorkerThreadLoop+0x14 1676ffa8 769ae456 76ab6f74 1676ffec 7c80b713 ole32!CRpcThread::WorkerLoop+0x1e 1676ffb4 7c80b713 0d3f6c40 044efa18 76ab6f74 ole32!CRpcThreadCache::RpcWorkerThreadEntry+0x1b 1676ffec 00000000 769ae43b 0d3f6c40 00000000 kernel32!BaseThreadStart+0x37 // Creating the DirectDraw thread to actually draw the window itself: 0:010> ~59kb ChildEBP RetAddr Args to Child 0469ff54 77d191be 77d191f1 0469ff98 00000000 ntdll!KiFastSystemCallRet 0469ff74 7cfceabc 0469ff98 00000000 00000000 user32!NtUserGetMessage+0xc 0469ffb4 7c80b713 00000000 7c932d58 00000000 quartz!ObjectThread+0x47 0469ffec 00000000 7cfcea75 000019e0 00000000 kernel32!BaseThreadStart+0x37 // The RPC call to create the new window: 0:010> ~58kb ChildEBP RetAddr Args to Child 0efafe14 7c92da8c 77e565e3 00000258 0efaff74 ntdll!KiFastSystemCallRet 0efafe18 77e565e3 00000258 0efaff74 00000000 ntdll!NtReplyWaitReceivePortEx+0xc 0efaff80 77e56caf 0efaffa8 77e56ad1 0018fef8 rpcrt4!LRPC_ADDRESS::ReceiveLotsaCalls+0x12a 0efaff88 77e56ad1 0018fef8 0ebff9bc 05033d40 rpcrt4!RecvLotsaCallsWrapper+0xd 0efaffa8 77e56c97 00171df8 0efaffec 7c80b713 rpcrt4!BaseCachedThreadRoutine+0x79 0efaffb4 7c80b713 149bcbf0 0ebff9bc 05033d40 rpcrt4!ThreadStartRoutine+0x1a 0efaffec 00000000 77e56c7d 149bcbf0 00000000 kernel32!BaseThreadStart+0x37 // IEFrame's message pump, which takes the new window call: 0:010> ~28kb ChildEBP RetAddr Args to Child 0927ed94 7c92df2c 7c809574 00000002 0927edc0 ntdll!KiFastSystemCallRet 0927ed98 7c809574 00000002 0927edc0 00000001 ntdll!NtWaitForMultipleObjects+0xc 0927ee34 77d195f9 00000002 0927ee5c 00000000 kernel32!WaitForMultipleObjectsEx+0x12c 0927ee90 5dff6029 00000001 0927eec4 ffffffff user32!RealMsgWaitForMultipleObjectsEx+0x13e 0927eeb0 5dff632d 000004ff ffffffff 00000000 ieui!CoreSC::Wait+0x49 0927eed8 5dff60d8 000004ff 00000000 424198bd ieui!CoreSC::WaitMessage+0x54 0927eee4 424198bd 039c9970 051c9650 00000000 ieui!WaitMessageEx+0x33 0927ef14 4240ab4c 052739b8 0927ef44 4240bbbb ieframe!CBrowserFrame::FrameMessagePump+0x199 0927ef20 4240bbbb 00000000 00000000 039c9970 ieframe!BrowserThreadProc+0x3f 0927ef44 4240bb09 10040001 02240006 00203138 ieframe!BrowserNewThreadProc+0x7b 0927ffb4 7c80b713 039c9970 02240006 00203138 ieframe!SHOpenFolderWindow+0x188 0927ffec 00000000 4240ba53 039c9970 00000000 kernel32!BaseThreadStart+0x37 // The mshtml thread to draw the innards of the new window: 0:010> ~56kb ChildEBP RetAddr Args to Child 106aff0c 7c92df3c 7c8025db 00002320 00000000 ntdll!KiFastSystemCallRet 106aff10 7c8025db 00002320 00000000 106aff44 ntdll!ZwWaitForSingleObject+0xc 106aff74 7c802542 00002320 000927c0 00000000 kernel32!WaitForSingleObjectEx+0xa8 106aff88 42adf4c5 00002320 000927c0 42a40000 kernel32!WaitForSingleObject+0x12 106affa0 42ad6bba 001a0348 0019f290 42a5d9ac mshtml!CDwnTaskExec::ThreadExec+0x127 106affac 42a5d9ac 106affec 7c80b713 1518b480 mshtml!CExecFT::ThreadProc+0x3c 106affb4 7c80b713 1518b480 001a0348 0019f290 mshtml!CExecFT::StaticThreadProc+0xd 106affec 00000000 42a5d99f 1518b480 00000000 kernel32!BaseThreadStart+0x37 // The network call for the contents of the new window: 0:010> ~52kb ChildEBP RetAddr Args to Child 0f5af118 7c92df3c 719b402b 000017d8 00000001 ntdll!KiFastSystemCallRet 0f5af11c 719b402b 000017d8 00000001 0f5af144 ntdll!ZwWaitForSingleObject+0xc 0f5af158 719b57c1 000017d8 0000179c 00000000 mswsock!SockWaitForSingleObject+0x1a0 0f5af1d0 71a167de 0000179c 0f5af208 00000001 mswsock!WSPRecv+0x1dd 0f5af218 6d4d6a10 0000179c 08e8a3a0 00004000 ws2_32!recv+0x83 WARNING: Stack unwind information not available. Following frames may be wrong. 0f5afa40 098382ff 08e8a3a0 0f5afaa4 0f5afaa0 net!Java_java_net_SocketInputStream_socketRead0+0x140 0f5afa80 09832a8f 00000000 09836509 00000000 0x98382ff 0f5afbb4 07a373ed 0f5afbe8 0f5afd8c 0000000a 0x9832a8f 0f5afc30 07a8fb96 0000000a 00000000 0f5afce4 jvm!AsyncGetCallTrace+0x1d048 0f5afc74 07a372be 07a372c2 0f5afd84 0f5afc98 jvm!jmm_GetLastGCStat+0x1082b 0f5afcc4 07a3701b 0f5afd84 08e7cfe4 07b34594 jvm!AsyncGetCallTrace+0x1cf19 0f5afd40 07a51e95 0f5afd84 08e7cfe0 08e7cfe4 jvm!AsyncGetCallTrace+0x1cc76 0f5afd94 07ac1325 08e78408 08e78408 08e78408 jvm!JVM_StartThread+0x186 0f5afdc0 07ac12f3 08e7e210 07a8d261 00000000 jvm!JVM_RegisterPerfMethods+0x2d930 0f5aff80 77c0a3b0 08e78408 00000000 00000000 jvm!JVM_RegisterPerfMethods+0x2d8fe 0f5affb4 7c80b713 08e68dc8 00000000 00000000 msvcrt!_threadstartex+0x6f 0f5affec 00000000 77c0a341 08e68dc8 00000000 kernel32!BaseThreadStart+0x37 // The URL we're waiting on data from: 0:000> da 0x14546bb8 14546bb8 "http://www.macaodaily.com/html/2" 14546bd8 "008-11/page.xml" I can't tell you why the socket is in a wait state (this all happens down in kernel once we get here), but I can tell you that IE isn't "hung", it's waiting on data. That means that there's either a problem going across the network itself, or there's a problem from the network card driver up through the IP stack into the kernel and back to IE. Since Java is reading from the socket buffer in a stream, any delay will cause what will appear to be a "hang" until the buffer is full and net.dll (the java component responsible for interfacing with the network components) releases the socket. You should probably take a closer look at what is installed on the network stack on this box, including any antivirus and firewall products, and also make sure your network drivers are the latest available versions as well. It's not IE (and probably not java either), but something deeper down into the kernel causing the delay.

Nothing better than lighting a candle with a flamethrower .

Actually, that card *does* look like it came out of a ComDial PBX or phone switch - I've only seen the innards of a few of those (spent most of my time on Nortel and Avaya units), but those are *exactly* what they look like if my memory hasn't faded too far in the last few years. Some of the older 3Com units had similar-looking cards, but they were a little more plug and play than the ComDial units, so it may not be a 3Com.

It actually appears to be saying it can't create or execute something, likely due to faulty dll registration or a service not being in the running state: # for hex 0x80080005 / decimal -2146959355 : CO_E_SERVER_EXEC_FAILURE winerror.h # Server execution failed # 1 matches found for "80080005" I'd suggest the following: 1. Open a command prompt, and execute the following commands: net stop wuauserv net stop bits Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BITS\Parameters /v ServiceDll /t REG_EXPAND_SZ /d %windir%\System32\qmgr.dll Reg add HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup 2. Open the Windows folder, and rename the folder SoftwareDistribution to SoftwareDistributionOld. 3. In the command prompt still open, execute the following commands: net start bits net start wuauserv 4. Restart the computer and then try to access Windows Update.

Heh - I think the picture sums it up, honestly.

Yes, if you read the MSDN article closely, the APIs changed from XP/2003 to Vista/2008, and the new APIs were at the top of the list.

Please read the book, as I've explained this twice now but you appear to still need some more basic explanations that are best left to the Windows Internals book.

Using these counters and the math, you're determining how accurate your perfmon readings are (determining the RAM footprint, and how accurate your "Available Bytes" counter is). Since you're within about 8-10MB after adding these counters and subtracting from 512MB, you can be fairly certain that your do indeed have somewhere near 350MB of 512MB available, so your RAM footprint is approximately 162MB (when this data was captured, of course). In your second set of data, opening applications made your working set total increase and caused a small cached bytes decrease - windows was likely lowering the amount of data in the cache so that more RAM was available for working set usage, and the working set increased because more apps were opened (thus more working set virtual address space to run program binaries and store process data). What you see is normal - I don't know how much clearer I can make this, this isn't Windows 101, and this is as basic as I can make it without it being totally useless.

Yes, the dmp file would be quite helpful - the wait you see in threads 0 and 1 are actually quite normal, and not the cause of your hang likely.

Your math. If you convert bytes to MB and then do the math, it's easier: Available = 352.539MB Cache = 41.015MB Pool Nonpaged = 14.648MB Working Set = 107.421MB RAM = 524.288MB sum = 515.623MB You end up with approximately 8.665MB unaccounted for (which, knowing that the #s are not entirely accurate due to shared pages, paging, etc, means this is pretty close - within 8MB). There's nothing wrong here.

Does Vista work? If it does, you can find out what chipset this laptop is using and perhaps find those drivers for XP. Again, I know nothing of this laptop, but it does look to use SATA as the bus.

True, AutoCAD was one I remember. Even if you don't have AutoCAD x64, you could still run older versions that are compiled LAA under x64 WOW and get 4GB VA - I know I would .

This isn't exactly true in all situations. 32-bit applications that are LAA (large address aware) can address up to 4GB of memory on Windows x64. True, but there aren't many. Most apps compiled this way are server-type apps (like SQL Server or Exchange, for instance). I was trying to keep it simple .

Set the power state(s) yourself? http://msdn.microsoft.com/en-us/library/aa373163(VS.85).aspx