cluberti

Yup. Looks like it's in a protected directory on the site:

Unfortunately, using a WIM file to image an XP machine still doesn't remove the limitations of the HAL. Using a WIM only gives you a file-based structure to store the base image, but it doesn't change the limitations XP has on the HAL. There are some other posts on the unattended XP section on ways to get XP to install on multiple hardware devices, but these are all independent of what imaging software you're using (ultimately, WIM won't help you achieve this).

Honestly, I've always found registry "cleaners" to be utter crap, and at the least dangerous. Since the registry is a database of program data, settings, etc for both Windows and the applications installed with no "listing" or history of what's been added or removed, nor by who, there's no real way for a cleaner to 100% know what it should leave, and what is 'safe' to delete. While I am sure registry corruption doesn't happen frequently with these, it's always a possibility. Also, in reality, even if you were to trim a few KB from the registry, what improvement or benefit would you actually get? With NT-based systems (NT, 2000, XP, Vista, Win7) you have a registry that is already fairly efficient, and also memory-mapped for faster access, and as such "bloat" (whatever that is) of the registry really shouldn't cause you any performance detriment, and conversely, you aren't going to really get anything valuable out of "cleaning" it either - the stuff you might really want to clean (locked / undeletable registry keys, malware, etc) can't be touched by these anyway, and require something deeper (like sysinternals tools, or an offline ERD disk). Registry "cleaning" is a holdover from the 9x days, when you really could get some benefit from trimming your registry down. Nowadays, however, I can't really see any benefit to it (especially considering you *could* permanently damage it if you aren't careful).

What you want to do is hide part of the shell, but you can't only hide "part" of it with explorer.exe. You'll have to write or use your own shell to do this, and present this to your TS users as the "log on program" in TS to replace the shell.

// It's a STOP 0x8E, meaning a kernel mode unhandled exception happened in a driver, thus the crash: 0: kd> .bugcheck Bugcheck code 1000008E Arguments c0000005 806ff94f b64cdb18 00000000 // The trapframe shows that it's failing during an Acquire of a FastMutex lock: 0: kd> .trap 0xffffffffb64cdb18 ErrCode = 00000002 eax=00000000 ebx=b64cdc50 ecx=00000001 edx=8a75b1e0 esi=8a7d83a0 edi=8a7ac6e0 eip=806ff94f esp=b64cdb8c ebp=b64cdb9c iopl=0 nv up ei pl nz ac po cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010213 hal!ExAcquireFastMutex+0xf: 806ff94f f0ff09 lock dec dword ptr [ecx] ds:0023:00000001=???????? // The thread, showing us talking to a filter driver on the system: 0: kd> !thread GetPointerFromAddress: unable to read from 80566eb4 THREAD 8a965960 Cid 0734.0168 Teb: 7ffa9000 Win32Thread: 00000000 RUNNING on processor 0 IRP List: Unable to read nt!_IRP @ 8a772db8 Not impersonating GetUlongFromAddress: unable to read from 80566ec4 Owning Process 0 Image: <Unknown> Attached Process 8a825490 Image: explorer.exe ffdf0000: Unable to get shared data Wait Start TickCount 2360 Context Switch Count 5 ReadMemory error: Cannot get nt!KeMaximumIncrement value. UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address 0x77f7422b Start Address 0x7c810856 Stack Init b64ce000 Current b64cd7fc Base b64ce000 Limit b64cb000 Call 0 Priority 10 BasePriority 8 PriorityDecrement 2 DecrementCount 16 ChildEBP RetAddr Args to Child b64cdb88 804f3548 8a7ac6e0 00000000 b64cdc50 hal!ExAcquireFastMutex+0xf (FPO: [0,0,0]) b64cdb9c f744fc06 8a7d83a0 8a75b1e0 00000000 nt!FsRtlLookupPerStreamContextInternal+0x14 (FPO: [Non-Fpo]) (CONV: stdcall) b64cdc00 f74601a7 8a75b1e0 8a7ac6e0 00000000 fltMgr!FltpGetStreamListCtrl+0x5a (FPO: [Non-Fpo]) (CONV: stdcall) b64cdc1c f744cac9 8a75b1e0 8a7ac6e0 8a75b1e0 fltMgr!FltpCleanupStreamListCtrlForFileObjectClose+0x17 (FPO: [Non-Fpo]) (CONV: stdcall) b64cdc38 f744cffb b64cdc50 8a772dc8 8abf4ae8 fltMgr!FltpPassThrough+0x93 (FPO: [Non-Fpo]) (CONV: stdcall) b64cdc68 804e13d9 8a79e020 8a772db8 8a772db8 fltMgr!FltpDispatch+0xf3 (FPO: [Non-Fpo]) (CONV: stdcall) b64cdc78 8057c403 8a7ac6c8 00000000 00000000 nt!IopfCallDriver+0x31 (FPO: [0,0,0]) (CONV: fastcall) b64cdcb0 8056c78f 007ac6e0 00000000 8a7ac6c8 nt!IopDeleteFile+0x132 (FPO: [Non-Fpo]) (CONV: stdcall) b64cdccc 804e1957 8a7ac6e0 00000000 000003d8 nt!ObpRemoveObjectRoutine+0xdf (FPO: [Non-Fpo]) (CONV: stdcall) b64cdce4 8056e9f4 8a825490 e264a6f0 8a965960 nt!ObfDereferenceObject+0x4c (FPO: [0,0,0]) (CONV: fastcall) b64cdcfc 8056e912 e264a6f0 8a7ac6e0 000003d8 nt!ObpCloseHandleTableEntry+0x155 (FPO: [Non-Fpo]) (CONV: stdcall) b64cdd44 8056e95c 000003d8 00000001 00000000 nt!ObpCloseHandle+0x87 (FPO: [Non-Fpo]) (CONV: stdcall) b64cdd58 804dd99f 000003d8 011bfaec 7c90eb94 nt!NtClose+0x1d (FPO: [Non-Fpo]) (CONV: stdcall) b64cdd58 7c90eb94 000003d8 011bfaec 7c90eb94 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b64cdd64) WARNING: Frame IP not in any known module. Following frames may be wrong. 011bfaec 00000000 00000000 00000000 00000000 0x7c90eb94 // Looking at the filter list by tracking down it's pool tag: 0: kd> .frame 2 02 b64cdc00 f74601a7 fltMgr!FltpGetStreamListCtrl+0x5a 0: kd> dt FileObject FsContext Local var @ 0xb64cdc0c Type _FILE_OBJECT* 0x8a7ac6e0 +0x00c FsContext : 0x8a7d83a0 // It's a device driver object: 0: kd> !pool 0x8a7d83a0 2 Pool page 8a7d83a0 region is Unknown *8a7d82b0 size: 4b8 previous size: 28 (Allocated) *Devi (Protected) Pooltag Devi : Device objects // Digging apart the device driver object to find the driver behind it: 0: kd> dt nt!_device_object 8a7d82b0+20 +0x000 Type : 3 +0x002 Size : 0x468 +0x004 ReferenceCount : 1 +0x008 DriverObject : 0x8aaa1788 _DRIVER_OBJECT +0x00c NextDevice : 0x8a7e8768 _DEVICE_OBJECT +0x010 AttachedDevice : 0x8a79e020 _DEVICE_OBJECT +0x014 CurrentIrp : (null) +0x018 Timer : (null) +0x01c Flags : 0 +0x020 Characteristics : 0 +0x024 Vpb : (null) +0x028 DeviceExtension : 0x8a7d8388 +0x02c DeviceType : 3 +0x030 StackSize : 12 '' +0x034 Queue : __unnamed +0x05c AlignmentRequirement : 1 +0x060 DeviceQueue : _KDEVICE_QUEUE +0x074 Dpc : _KDPC +0x094 ActiveThreadCount : 0 +0x098 SecurityDescriptor : (null) +0x09c DeviceLock : _KEVENT +0x0ac SectorSize : 0x800 +0x0ae Spare1 : 1 +0x0b0 DeviceObjectExtension : 0x8a7d8738 _DEVOBJ_EXTENSION +0x0b4 Reserved : (null) // The DeviceExtension is completely invalid: 0: kd> dt fltmgr!FSRTL_ADVANCED_FCB_HEADER 0x8a7d8388 +0x000 NodeTypeCode : 0 +0x002 NodeByteSize : 0 +0x004 Flags : 0 '' +0x005 IsFastIoPossible : 0 '' +0x006 Flags2 : 0 '' +0x007 Reserved : 0 '' +0x008 Resource : 0x8a7d8390 _ERESOURCE +0x00c PagingIoResource : 0x8a7d8390 _ERESOURCE +0x010 AllocationSize : _LARGE_INTEGER 0x0 +0x018 FileSize : _LARGE_INTEGER 0x8a9aac38`03980302 +0x020 ValidDataLength : _LARGE_INTEGER 0x8a97e9b0 +0x028 FastMutex : 0x8a9aa218 _FAST_MUTEX +0x02c FilterContexts : _LIST_ENTRY [ 0x0 - 0xb832c468 ] // Looking at the memory for this, it's vobiw.SYS: 0: kd> dds 0x8a7d8388 8a7d8388 00000000 8a7d838c 00000000 8a7d8390 8a7d8390 8a7d8394 8a7d8390 8a7d8398 00000000 8a7d839c 00000000 8a7d83a0 03980302 8a7d83a4 8a9aac38 8a7d83a8 8a97e9b0 8a7d83ac 00000000 8a7d83b0 8a9aa218 8a7d83b4 00000000 8a7d83b8 b832c468Unable to load image vobiw.SYS, Win32 error 0n2 *** WARNING: Unable to verify timestamp for vobiw.SYS *** ERROR: Module load completed but symbols could not be loaded for vobiw.SYS vobiw+0x1f468 8a7d83bc b832c468 vobiw+0x1f468 8a7d83c0 00000000 8a7d83c4 00000000 8a7d83c8 00000001 8a7d83cc 00000000 8a7d83d0 00000000 8a7d83d4 00000000 8a7d83d8 00000000 8a7d83dc 00000000 8a7d83e0 00000001 8a7d83e4 e1c31338 8a7d83e8 8aa16e38 8a7d83ec 8a9ea440 8a7d83f0 0000000a 8a7d83f4 8a7e3e78 8a7d83f8 8a7d83f8 8a7d83fc 8a7d83f8 8a7d8400 01000013 8a7d8404 00000000 It seems that at some recent time, a filter driver installed on this machine was updated with a mini filter driver. Installing mini filter drivers causes filter manager to do additional checks on loaded drivers and their contents, and it appears that the Pinnacle Systems' filter driver (vobiw.SYS) has a bug. This driver is from 2004, so I'm suggesting contacting them for a newer version that has this bug fixed.

Not seeing the attachments...

A 6161 error from a print spooler or a print job means the process is out of GDI resources. This would indicate that a print driver in the spooler is allocating GDI resources to create the print job, and not releasing them when it's done (this is normal for crappy print drivers, especially older HP and Lexmark drivers). Your best bet is to consider a few things: 1) Don't put your print spooler on a domain controller 2) Use *only* inbox drivers *wherever* possible - if you *have* to install a vendor driver, test it on a test print server first to see how it will act 3) Have a secondary print server that matches your production print server so you can test drivers, changes, etc before changing production - you can use the Microsoft printmig tool to do this.

This thread is being closed. We've received a notice from our hosting provider that a 3rd party has notified us that a violation of the Adobe EULA was found on MSFN in this thread, and indeed upon review Adobe does not allow redistribution of their binaries in any way. As such, this is a violation of a EULA and Adobe's copyright, and in accordance with our own forum rule 1.b, the links have been removed, the thread closed, and notification given as to why.

If you do enough imaging, sometimes it pays to set up a separate network segment (with faster speeds) dedicated to imaging only. When I was an admin of a few thousand machines all in one building, we had a separate network segment for this that was 1Gb (when it was still relatively new) with just a deployment server and a switch - once the machines were imaged, they'd get turned off and sent back to their regular switch ports to be booted onto the network.

I agree with nitro - I get sub 3 second loads of Word 2007 on this older Vista box. It's got Vista SP1, an AMD Athlon 2600, a single 60GB IDE HDD, and 1GB RAM running aero on an ATI x200 POS. If it takes you more than 3 or 4 seconds, unless you're on REALLY old hardware or 512MB RAM, it should NOT take that long to open Word.

No, you just need it to crash. You'd only do that if you wanted to crash it via the keyboard on purpose.

You really need to at least change the dump type to kernel (and honestly, I'd prefer a *complete* memory dump, as per the instructions in the sticky at the top of this section). Because otherwise, I have no idea what's happening. The dump does indicate that a device was attempted to be accessed that doesn't exist under the hardware_disk category, but that could mean anything (including virtual CD drives, a mounted device, a network device, anything). I need to see the other end of this LPC chain, which doesn't exist in a minidump. 0: kd> !thread GetPointerFromAddress: unable to read from 80562134 THREAD 86c2aa58 Cid 025c.02bc Teb: 7ffd6000 Win32Thread: e284ac70 RUNNING on processor 0 Not impersonating GetUlongFromAddress: unable to read from 805621cc Owning Process 0 Image: <Unknown> Attached Process 86d25020 Image: csrss.exe ffdf0000: Unable to get shared data Wait Start TickCount 605693 Context Switch Count 1019 LargeStack ReadMemory error: Cannot get nt!KeMaximumIncrement value. UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address 0x000045aa LPC Server thread working on message Id 45aa Start Address 0x75b44616 Stack Init a9f1d000 Current a9f1cc34 Base a9f1d000 Limit a9f1a000 Call 0 Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 16 ChildEBP RetAddr Args to Child a9f1c520 805d1ac5 000000f4 00000003 86d25020 nt!KeBugCheckEx+0x1b (FPO: [5,0,0]) a9f1c544 805d2a27 805d297c 86d25020 86d25194 nt!PspCatchCriticalBreak+0x75 (FPO: [3,0,0]) a9f1c574 8054162c 86d25268 c0000006 a9f1c9b0 nt!NtTerminateProcess+0x7d (FPO: [2,4,4]) a9f1c574 80501161 86d25268 c0000006 a9f1c9b0 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a9f1c584) a9f1c5f4 804fe816 ffffffff c0000006 a9f1c9f8 nt!ZwTerminateProcess+0x11 (FPO: [2,0,0]) a9f1c9b0 805028cf a9f1c9d8 00000000 a9f1cd64 nt!KiDispatchException+0x3a0 (FPO: [Non-Fpo]) a9f1cd34 80544ef7 00bcfbe8 00bcfc08 00000000 nt!KiRaiseException+0x175 (FPO: [Non-Fpo]) a9f1cd50 8054162c 00bcfbe8 00bcfc08 00000000 nt!NtRaiseException+0x33 a9f1cd50 75b7b3b9 00bcfbe8 00bcfc08 00000000 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a9f1cd64) WARNING: Frame IP not in any known module. Following frames may be wrong. 00bcfff4 00000000 00000000 00000000 00000000 0x75b7b3b9 0: kd> !lpc message 45aa Reading LpcPortObjectType failed Reading LpcWaitablePortObjectType failed The values for LpcPortObjectType or LpcWaitablePortObjectType are invalid. Please check the symbols. Note that csrss.exe is not your problem, but csrss.exe is crashing as the victim of something else. Again, we need at least a kernel dump, and preferably a complete dump, before we can give you anything from this. Minidumps are useless, I'm honestly not sure why they're the default option for dump types in Windows - I wish this would change.

It does not, someone copied those there.

DFS is a mirrored file system, fronted by a "virtual" server name that points you to (hopefully, if configured properly) the closest replica of the DFS to your location. However, because all servers in the grouping are aware of whether or not other replicas are down (similar to heartbeats in clusters or web farms), and you're never accessing a DFS replica server directly (you access it via the DNS DFS namespace root name in AD or in the root of the non-AD-integrated DFS) when you go to hit a server you are directed to another replica if the closest to yours is down. Obviously there can be issues with data availability on a remote replica depending on whether or not what you have on the DFS share has been replicated, but the article is correct, if one node is down you will be re-routed to another without you really knowing it without looking at network traffic.

I get about 7GB down to my Vista clients over PXE in about 5 minutes, although I've seen it take up to 10 when I'm really hammering the server with 15 - 20 clients at a time. One machine takes 3 - 5 minutes, however. It's probably worth noting that I am also using Server 2008 WDS in multicast mode, and I am using a Gig-E network. When I was using Server 2003 and WDS, times were much longer (between 15 - 20 minutes for the same exact image on the same exact network).

From the debugger: I'm assuming you cannot boot in safe mode at all, or last-known good? It's at least very likely that removal of a virus from the system has messed up her registry hives, and if you can't get a dump file or boot in any safe mode you're probably SOL. A repair install *might* work, but she will lose some installed programs potentially and have to reinstall.

When a device responds like this, it will show your client IP (as you are seeing) stating that it's not able to communicate at all with the remote host (Destination host unreachable). I would consider getting a network trace from your client whilst pinging 10.1.1.1 via wireshark or netmon to see what's actually happening. Is the router actually not responding to the ICMP requests, or is something on the client causing it? Hard to say without that raw packet data.

Each time you open a new tab or window, generally speaking (not always, but usually) you will get a new iexplore.exe process. This is expected behavior - however, the processes are supposed to go away after approximately 60 seconds after a tab or window is closed, so some add-in or BHO is probably holding them open. Can you reproduce the problem if you start IE8 with the -extoff switch from the command line (or the start bar): iexplore.exe -extoff ? This is described here: Closing an IE 8 TAB does not immediately close the spawned iexplore.exe process How to determine which IE tabs goes to which Iexplore.exe process when using Internet Explorer 8 Opening a New Tab may launch a New Process with Internet Explorer 8.0 Clicking on the blue “e” in taskbar does not launch a new process in IE8

If you have one license for Windows and 5 CALs, it means you can install it one time on one machine, and have 5 client machines (hence the term Client Access License) access whatever services the CALs are for (in the case of Windows CALs, these would cover things like file shares or print queues, for instance).

Download/install wireshark, open up the app, start the capture, open a cmd prompt, run ipconfig /renew, and then stop and save the capture to a .cap file in wireshark. Post it somewhere it can be downloaded, and we can help.

?

I'd suggest starting a network trace via wireshark or netmon from a client, then run "ipconfig /renew" and see what happens on the wire. Is the DHCP server responding to the client's DISCOVER or REQUEST packets? If so, is it responding with an ACK (the OFFER or ACKNOWLEDGE response) or a NACK (not allowed)? If it's running, you need to see if it's actually *receiving* requests and denying them, or not responding at all to DISCOVER or REQUEST packets.

Even if I boot from the DVD? With the 64-bit hardware installed? And my data coped to another hard-drive? Yes, even if you do everything like you would in x86. It is simply not possible to upgrade from x86 to x64, as they're not the same OS (especially with XP - XP x64 is really Server 2003 under the covers). It's documented lots of places, but the most direct is here: Note that this applies for Server 2003 and Server 2008, Vista, and will apply for Windows 7 too.

First, note that this information was found very quickly and easily via a google search. You are incorrect, Microsoft (for licensing) counts SOCKETS, not CORES (or virtual hyperthreaded CPUs), for Windows. There are caveats for SQL Server and Exchange server licensing, for instance, but for Windows itself, Microsoft counts SOCKETS (a quad-core CPU would license as ONE cpu in Windows XP, Windows Server 2003, or Windows Server 2008 - and a CPU that exposes a "virtual CPU" via hyperthreading also does not incur a license cost for that virtual HT CPU either - only the socket).It's laid out VERY clearly right here. It's very clear and obvious that Windows licensing is PER SOCKET. The relevant text from the article:

No, you cannot upgrade from x86 to x64 with any version of Windows. You will always have to perform a clean install.