cluberti

Well, your Dell tech should probably read his knowledgebase. I don't even work for them and I know that on most Dell laptops and older Dell desktops, the default IDE idle spin down period is 3 minutes. Any time the drive fails to spin down, the machine will emit a soft, almost inaudible BEEP (... every 3 minutes - sound familiar?). Your hard drive is indeed suspect at this point, I would contend.

Did you integrate anything specific into your ISO? I verified your file against a default XP SP3 txtsetup.sif, and all of the stock Windows stuff was there - so I'm guessing something integrated (or I guess, perhaps, removed) is no longer referenced in the .sif file, causing the error. The fact that the key is "." rather than a file or folder name also hints at this as well.

You're assuming the developer of the app even tested his/her code on a slow link. Wininet doesn't control buffer size or whether or not it waits for a server ACK response, those are all handled at the winsock level (below wininet and outside the purview of Internet Explorer). Since upgrading to IE7 causes this behavior, this likely means your app vendor didn't write a winsock app, but an app that uses IE components. The networking component is wininet.dll, and there are no changes in wininet.dll with regards to network behavior between 6 and 7, so that leaves the developer's code - again, I'd wait for them to respond. What is happening would have little to do with the IE component themselves, and more to do with how the vendor is using them. Also, if you install IE8 beta 2, does the problem show up there?

Are you talking about: Key: HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management Value: PagedPoolSize Type: REG_DWORD Radix: Hexadecimal Data: FFFFFFFF Value: PoolUsageMaximum Type: REG_DWORD Radix: Decimal Data: 20 Or is this a specific value to a McAfee registry key?

Antec, CoolerMaster, PC Power & Cooling, and Enermax (in no particular order) all make very good PSUs. I haven't used CoolerMaster or PCPC units in a while, but I remember them being quite good. I'm partial to Enermax MODU82+ parts at the moment, although the PRO series are good as well.

The problem is that the file/folder is potentially linked to index.dat, which will get a handle to the file any time winlogon is running (which is all the time). Meaning, you will not (easily) be able to whack it without bugchecking the box, hence it doesn't get deleted. You are going to need a bootable CD with access to the filesystem to get rid of this, I would think.

Is this the McAfee HBSS/HIPS system?

Looks like you still run into the zero window size set by the server, but the server resets the window size back to 32767 after 4.2 seconds instead of 53.

Well, it looks like the problem may be specific to TCP window sizes - everything looks to be fine until the server (around 18 seconds in) starts shrinking the window size down eventually to 0, and then 53 seconds later resets the window size back to 32K and the transfer completes. I don't know specifically what on the client would cause the server to behave as if it's not keeping up with it's receive buffer, but I would suggest contacting the vendor (Winscribe) to see if there would be any known issues with this version of the app and IE7. Again, it is behaving as if it's overloading the server's receive buffer, and I can't think of anything client-side that would cause this (but it does appear possible).

902973 You occasionally receive a "STOP 0x000000D1" error message when you start or shut down a Windows XP-based computer or a Windows Server 2003-based computer http://support.microsoft.com/default.aspx?...kb;EN-US;902973 In debugging it, you're seeing a crash on USBPORT!USBPORT_RemoveBadReqIrp+0x6b: 0: kd> !thread 80560ca0 THREAD 80560ca0 Cid 0000.0000 Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0 Not impersonating Owning Process 0 Image: <Unknown> Attached Process 80560f00 Image: Idle Wait Start TickCount 84691 Ticks: 96 (0:00:00:01.500) Context Switch Count 317428 UserTime 00:00:00.000 KernelTime 00:20:35.984 Stack Init 80556700 Current 8055644c Base 80556700 Limit 80553700 Call 0 Priority 16 BasePriority 0 PriorityDecrement 0 DecrementCount 0 ChildEBP RetAddr Args to Child 8055620c f81a02b5 badb0d00 00000004 8234f028 nt!_KiTrap0E+0x238 (FPO: [0,0] TrapFrame @ 8055620c) 80556284 80514574 41426d72 806228bb 8234f0e0 USBPORT!USBPORT_RemoveBadReqIrp+0x6b (FPO: [Non-Fpo]) (CONV: stdcall) 8055629c f81a0085 8234f102 00000000 8234f0e0 nt!IoCsqRemoveNextIrp+0x3d (FPO: [Non-Fpo]) (CONV: stdcall) 805562bc f81a0650 8234f028 00000000 f81a04ec USBPORT!USBPORT_BadRequestFlush+0x3b (FPO: [Non-Fpo]) (CONV: stdcall) 805562e0 804e2b4e 8234f70c 8234f028 87b967e9 USBPORT!USBPORT_DM_TimerDpc+0x164 (FPO: [Non-Fpo]) (CONV: stdcall) 805563fc 804e207d 80560f00 ffdff9c0 ffdff000 nt!KiTimerListExpire+0x14b (FPO: [Non-Fpo]) (CONV: fastcall) 80556428 804dcd22 80561300 00000000 00014b32 nt!KiTimerExpiration+0xb1 (FPO: [Non-Fpo]) (CONV: stdcall) 80556450 804dcc07 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61 (FPO: [0,1,0]) 80556454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28 (FPO: [0,0,0]) 0: kd> !irp 806228bb 1 Irp is active with 3 stacks 3 is current (= 0x858bf640) No Mdl Thread 00000000: Irp stack trace. Flags = 00000000 ThreadListEntry.Flink = 806228bb ThreadListEntry.Blink = 806228bb IoStatus.Status = 00000103 IoStatus.Information = 00000000 RequestorMode = 00000000 Cancel = 00 CancelIrql = 0 ApcEnvironment = 00 UserIosb = 00000000 UserEvent = 00000000 Overlay.AsynchronousParameters.UserApcRoutine = 00000000 Overlay.AsynchronousParameters.UserApcContext = 00000000 Overlay.AllocationSize = 00000000 - 00000000 CancelRoutine = 00000000 UserBuffer = 00000000 &Tail.Overlay.DeviceQueueEntry = 00cfcf6c Tail.Overlay.Thread = 00000000 Tail.Overlay.AuxiliaryBuffer = 00000000 Tail.Overlay.ListEntry.Flink = 00000000 Tail.Overlay.ListEntry.Blink = 00000000 Tail.Overlay.CurrentStackLocation = 858bf640 Tail.Overlay.OriginalFileObject = 00000000 Tail.Apc = 00000000 Tail.CompletionKey = 00000000 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 >[ f, 0] 0 e1 857d4030 00000000 f6bed854-857d5d30 Success Error Cancel pending \Driver\usbuhci usbhub!USBH_ChangeIndication Args: 857d5e84 00000000 00220003 00000000 0: kd> !devext 857d5d30 USBHUB Dump Hub Device Extension: 857d5d30 1 HUB HUB FDO 857d5c78 PDO 857d4030 TOS 857d4030 RootHub 857d4030 HcdTos 857d4030 FLG: HUBFLAG_NEED_CLEANUP HUBFLAG_SUPPORT_WAKEUP Status: HubChange 0 IRP 806228bb Buffer 85bc5660 len 8 Desc 858b5e80 PowerIrp 0 PendingWake 0 #PortWake 0 PortData 858cd3e0 size 2 Port 0 change 0 Status 100 PORT_STATUS_POWER Port 0 change 0 Status 0 Config Handle 859aeaf0 ConfigDesc 857db838 PowerTable 0 1 3 4 4 4 4 Current 1 Pending Req 2 ErrorCount 2 DeviceDesc 50005 PipInfo 1 Urb 857d5e50 This is indeed a bug in the XP usbport.sys driver, but it's not fixed. You can avoid this by disabling the ability for XP to put any devices on the USB bus to sleep in the device manager under USB controllers, under each USB hub, properties, power management - uncheck "allow the computer to turn off this device to save power".

First, the MSDN description of how to defragment a volume via code - these are the functions most defragmenters for windows use when defragmenting a volume, so at least understanding that these exist will be a good start. Obviously these APIs only provide information about the filesystem, it's up to the app that's calling them to determine what to do with a file or cluster, etc. Note it goes FAR deeper than what I'm about to skim over (DeviceIOControls, IOCTLs, GetFileMap, GetVolumeMap, etc), but this is just a very, very basic high-level overview of how it "works". Ultimately, your answer really comes down to how the defrag program is configured to run - some try to put all of the files in a contiguous area, some try to do other things, etc. As to what happens with the file, generally the MoveFile API is used to move a file (and it's fragments) once it's been targeted to "defrag" to move it to another area of disk, and yes this means files are generally copied into and out of the running defragmenter's process address space, which usually means RAM (but could be paged to disk, technically, if needed, but that's likely not a normal scenario). In general, most apps will say at least 15% of the drive needs to be available for defragmentation, but I've found it's more like 25% (and that free space can't be heavily fragmented either, or it's extremely hard to move files around). In general, if you've less than 25% free space on a drive, defragmenting it becomes difficult. Not impossible, but difficult (and may require your defrag program to take multiple passes at a file system to get it "defragged", etc).

1. It's likely a display bug (race condition between displaying the link and refreshing the status bar). I would suggest filing it on the forums for IE8 though, if you can repro it easily. 2. Yes, it's a render issue - if enabling compat mode for that site fixes it, they're probably sniffing your user agent and giving you an ie-specific page that isn't standards-compliant, which should lead you to send an email to webmaster@<domain> about IE8 compat for that site.

Once you try the key in Vista and it fails, can you run a diagnostics report? http://go.microsoft.com/fwlink/?linkid=52012

No, not true. That's an Intel 965 chipset, which means a GME965 with the x3100 video chipset. DX10 support, sure, but it's using the main CPU to do most of the work. Testing without Aero is actually recommended (not as a fix, but as a troubleshooting step) to see if this is taxing enough to cause the symptoms or not. Again, no. Disabling superfetch and readyboost limit disk access by the OS, and disabling indexing also removes the searchindexer.exe and searchprotocolhost.exe hits on the hard drive, making these valid troubleshooting steps.Remember, we're troubleshooting, not "fixing". I recommend them to see if it's a disk issue, or a graphics chipset issue (especially with Intel onboard video), etc. Your suggestions of disabling startup items and sidebar gadgets are also good, but saying that the things I suggested don't hamper performance (especially on a laptop) are incorrect at best. These ARE good troubleshooting steps to narrow down the source of the "slow" behavior, and then troubleshoot from there.

No, just undocumented feature/change was all I was hinting at. We don't know what is happening (documented or otherwise) because we still don't have a network trace . What is likely though is that the app is using wininet for network and state information, and upgrading to IE7 upgrades wininet.dll, thus causing some behavioral change (could be a poorly written app too, remember).

Ok so wireless is out of the question thats good. As for IE7 being involved, to me the microsoft ethos has always seemed "how can restrict the user further" so I agree it lies with an IE7 design flaw/change hence why I am suggesting some of the common IE patches/changes most people should make on a fresh install. Does this happen with a fresh install of IE7? if not then have you tried the IE7 reset feature?(http://support.microsoft.com/kb/923737) Maybe an IE7 install sets some networking restrictions outside of IE7, you know as sort of a hidden bundled update/feature. You will probably need to provide more information to get responses from other members. Wow - tinfoil hat?

Also, keep in mind how many 302 redirects your app is sending - IE7 caps the redirect hop limit at 10, IE6 had no such limit by default. Also, more info on what is happening (perhaps a network capture of the problem?) would be useful. Otherwise, we're just guessing like this.

You are correct, I was thinking of something else. Haven't used vLite in awhile now, more of an nLite user way back when. I use MDT for everything nowadays.

It isn't university speeds, but it's close - and it's just an AT&T connection at work: Probably would be faster later in the evening.

If you want to *preinstall* apps into a vista WIM, consider using MDT 2008 (Update 1) and the WAIK to set up, install, create, and then .ISO the image itself. If you want a disc that installs apps after Vista, you can use vLite or the WAIK. MDT 2008 can actually do this as well, so it's also an option.

Well, the next question is (assuming you've already disabled superfetch/readyboost/windows search services), what do you have installed on the machine, and what does procmon say is happening on the box whilst you're waiting for periods of time for things to happen (disk accesses by which processes, which files, registry accesses, etc)?

DO NOT DOUBLE POST. You have been warned TWICE. Do it again and you're banned. [Closed].

It's not possible to uninstall Win7 at the moment. Moral of the story, don't install a beta over a working, non-beta OS. Dual boot or use a separate drive entirely. [Closed].

If restarting the ADDC on the 2008 box resolves the issues for a time, it would appear that it's likely there is a resource leak in the ADDC service process - could be memory, could be a blocking queue growth, etc. Performance Monitor, tasking against this specific process, might be your best place to start. Also, include the memory counters for all processes on the system (not _TOTAL, but all individual processes): Under the "Process" object, selecting :<All instances>", add: - Handle Count - Pool Nonpaged Bytes - Pool Paged Bytes - Private Bytes - Virtual Bytes - Working Set - Working Set - Private

What happens when you try to join the domain with the x60? I've not heard of or seen any problems with the x60 specifically after sysprep on SP3, so a little more info other than "it won't join the domain" would be quite helpful. Like, error messages, network traces, etc.