cluberti

I didn't realize you were still hosting - I was under the impression that was more temporary way back when. As far as a wager, I'll give you a raise to 2x what I'm paying you now .

I'm not really sure what you don't understand - I would suggest keeping the .exe files on the CD, in the $oem%\$1\TEMP folder, which will then get copied to the hard disk during setup (for example, C:\temp). When RunOnceEx is executed after setup completes (if you're following the guide), you can call the executables to set up the programs from C:\TEMP. The guide is very self-explanatory, so if you're not understanding it, I would suggest setting up a virtual machine and learning via trial-and-error. The RunOnceEx stuff in the guide here might not be deployment 101-level stuff, but it's level 103 or 104 - if you're having trouble with it, honestly, your best bet might be just to try and learn from your mistakes in virtual machines.

Using RunOnceEx itself is documented here: http://unattended.msfn.org/unattended.xp/view/web/31/SESSID=d7bfdd16201f2117429ef6a8e70aa94b/

Please do not double-post. I've closed the other thread, although jaclaz's response is quite good there.

Please do not double post.

What kind of activity are you looking to track? Would something like Process Monitor meet your need?

Topic edited to be more accurate - this is not the RTM release.

True, but I see a lot of folks using IE6 SP1, DirectX, and/or Windows Media Player binaries from Win2K updates on their 9x systems, so this is of note for those folks.

Just FYI, for anyone who looks for / relies on these things. There will be no more publicly released patches for vulnerabilities in Windows 2000 and it's components.

Either it really is getting that much data moved during the test, or perhaps the firmware's been tuned to perform better on WinSat tests? How old is that drive?

A file being accessible over the network has nothing to do with it being actually written to disk. All I/O access goes through the ntfs.sys filter driver (and any other upstream filters installed) to provide access to the raw filesystem, which can mean serving data from a file cache versus the *actual* file on disk. NTFS can cache data, depending on how busy the server's disks are, for days, sometimes even weeks, depending on how much data is in the cache. If the server is just a web server and doesn't do much disk writing otherwise, I could see it taking many, many days to actually flush IIS log files to disk. If you're comparing NT4's NTFS on a webserver to FAT32 as your comparison point, you'll get little complaints from me. NT4's NTFS was pretty impressive in it's day, but that day was almost 15 years ago. NTFS has gotten MUCH better since then, so I'd suggest you revisit your statement from before of "This is an NT4 server running IIS 4 (hey, sure I can update it to server 2008, but it runs fine so why mess with it?).". I would argue running something business-critical on NT4 is a bit dangerous, and if you aren't going to upgrade to at least Server 2003 / IIS6, you should switch to FAT32 or disable write caching on your NTFS log volumes at this point. I'd suggest B, but A is something you can consider. The algorithms have been tweaked in the filesystem filter driver (in W2K, I think) to specifically make sure things like this on a low-volume write server (like an IIS server) doesn't happen. I've had this problem before on NTFS NT4 systems, and upgrading them to W2K did resolve the issue. I'd suggest 2003 at least, but given you don't seem to need supportability or security hotfixes, etc, 2000 might be fine. Not sure where you would have read that, but that is untrue. The version of the FS is not changed, but certain structures can be modified based on how newer versions of NTFS are structured (the underlying format of the filesystem does not change). It could cause a problem, so it might be worth testing by simulating a power failure without mounting the drive on the XP system to see if you get the same behavior. I would think you would, but it is always worth investigating possibilities.

As to registering on opening, no - that won't happen. As to changing the entries, I have never tried, so I honestly do not know.

The only other thing would be if it was on a network share and not local - make sure oplocks on the server hosting the file aren't causing the issue as well.

That error usually means the system has an open connection in that session to the server already - given that both XP and 2003 use session 0 for everything, if another account that's currently logged on to session 0 already has a connection open to the same network name, that's the error you'll get (and using the IP address is likely to work when name fails, unless of course you've already got one of those too ). I used to see this mostly when someone would map a drive with a service account, or a scheduled task, and then sleep/hibernate and wake back up, and the mapped drive would fail as the interactive user. Grab TCPView from sysinternals and see if you can kill the connectoid and TCP connection, and re-create it. It's not really a long-term solution (it will depend on how the drive is getting mapped in the first place), but it is something to try to make sure this is really it.

Usually on an NTFS-based system, corrupted files are actually corrupted (even text files), so seeing a file size *exactly* the same, but with garbage, would lead me to believe that file caching is the more likely culprit here, and when the system goes down whatever hasn't actually been *written* to the disk itself (it's still either in memory on the system or in the disk cache) is what you see as NULL chars in the file itself. Obviously fixing the problem with the power would be a better solution, and I don't remember NT4 much these days, but disabling write caching if it's possible on those log disks is probably a good idea. You really shouldn't be caching on any disk that contains log or transaction files anyway, for this specific reason.

ARP shows the installed hotfixes, whether or not they can be removed. This appears to be expected behavior, as I've just built a quick test to verify.

Always glad to hear a problem is solved, whether I had input or not .

That's expected - ieframe.dll only gets it's registration and configuration information on the box from the setup routine for IE7 or IE8 (or, of course, being preinstalled with the OS as on Vista/IE7 or Win7/IE8). It has no DllRegister function, and as such, you cannot register or un-register it. You can modify, delete, add, etc. it's registry information manually, of course, but you can't use the .dll to do it.

I would have to agree - a device using ~$1USD of power a year (in standby) is still $1USD, but appliances (not sure what you've got in your home) are the largest consumers of electricity in a normal home, followed closely by lighting and heating (A/C units use the most, but not everyone would have one of those depending on where you lived and the climate, etc). It was cost effective to seal up the house as well as could be done with the structure we had, install energy-efficient appliances, use the A/C and heat less, and put the computer to sleep (not off) when it wasn't in use. Saved quite a bit, and paid for itself in about a year.

If you use something like MDT to build the installation media, it will apply updates and hotfixes (and other msp packages) during the initial install if they apply to that OS install.

Ah, OK, I understand. I'm not sure of how we'd do something the logic board doesn't support though, as all of this is handled in firmware from the printer. If some sort of function to actually turn the device off without pressing the power button doesn't exist in the printer's logic board itself, you aren't going to be able to emulate it in software - what would you call? You could probably look at the microcode stored on the logic board itself if you don't mind taking it apart, have the tools to do this, and know where the microcode is stored and in what language(s) it is written in, but there's not going to be a windows-side function for this until or unless the printer supports doing it as well remotely over a serial, parallel, or USB connection. It supports the standard power properties that any external device supports, but an actual power on or power off event is a completely hardware-dependent function. Unless the device exposes in it's microcode the equivalent of a BIOS Int19 call, you're not going to be able to do this. Canon could probably answer this for you if you were to find the right person to ask, but that is probably not something you'll get from a newsgroup as that would involve exposing the inner-workings of their device(s), which I'm guessing is a trade secret they're not going to provide you.

The crash looks like heap corruption, but it's hard to say without pageheap enabled whether the free failure is caused by the Explorer breadcrumbs extension, or if it's just a victim of the WMP shell extension: // Actual crashing thread: 0:004> kn # ChildEBP RetAddr 00 00dfd478 774fd01c ntdll!RtlFreeHeap+0x44e 01 00dfd48c 774fd057 ole32!CRetailMalloc_Free+0x1c 02 00dfd49c 00f83afa ole32!CoTaskMemFree+0x13 WARNING: Stack unwind information not available. Following frames may be wrong. 03 00000000 00000000 BCToolbar!DllUnregisterServer+0xf4ba // CPU registers at the time - looks like copying the (poi) contents at 00001f62 to 00001cea: 0:004> r eax=00001cea ebx=00000000 ecx=00001f62 edx=00090608 esi=00116938 edi=00090000 eip=7c928c0b esp=00dfd3bc ebp=00dfd478 iopl=0 nv up ei pl nz na po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000203 ntdll!RtlFreeHeap+0x44e: 7c928c0b 8b11 mov edx,dword ptr [ecx] ds:0023:00001f62=???????? // Looks like both source and destination addresses are bogus: 0:013> dc 00001f62 L1 00001f62 ???????? ???? 0:013> dc 00001cea L1 00001cea ???????? ???? // Exception record showing what actually failed: 0:004> .exr ffffffffffffffff ExceptionAddress: 7c928c0b (ntdll!RtlFreeHeap+0x0000044e) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 00001f62 Attempt to read from address 00001f62 // Looking at the base to stack pointer, we can see the call to CoTaskMemFree: 0:004> dds 00dfd3bc 00dfd478 00dfd3bc 00ec4b20 00dfd3c0 00ec4b20 00dfd3c4 00000000 00dfd3c8 00000000 00dfd3cc 00000000 00dfd3d0 000fa630 00dfd3d4 00dfd3e4 00dfd3d8 774fd057 ole32!CoTaskMemFree+0x13 00dfd3dc 00000000 00dfd3e0 00df910a 00dfd3e4 00dffc28 00dfd3e8 1657ec8f WpdShext!DllUnregisterServer+0xed36 00dfd3ec 00000000 00dfd3f0 00000003 00dfd3f4 16525072 WpdShext+0x25072 00dfd3f8 1652507d WpdShext+0x2507d 00dfd3fc 00dfd520 00dfd400 00001f62 00dfd404 00dfd418 00dfd408 00001cea 00dfd40c 00116938 00dfd410 00000824 00dfd414 00125ff0 00dfd418 00016280 00dfd41c 00000000 00dfd420 00000000 00dfd424 00ec4b70 00dfd428 00dfd4f4 00dfd42c 7c910041 ntdll!RtlFreeHeap+0x1e9 00dfd430 00000018 00dfd434 00000003 00dfd438 00ec0000 00dfd43c 00dfd234 00dfd440 00090000 00dfd444 00116938 00dfd448 7c90e920 ntdll!_except_handler3 00dfd44c 7c9101e0 ntdll!CheckHeapFillPattern+0x54 00dfd450 00000000 00dfd454 00000000 00dfd458 010116b3 explorer!CMenuItemsCache::GetAppInfoFromSpecialPidl+0x43 00dfd45c 00ec0000 00dfd460 00dfd3bc 00dfd464 00dfcfe0 00dfd468 00dfd4c4 00dfd46c 7c90e920 ntdll!_except_handler3 00dfd470 7c910060 ntdll!CheckHeapFillPattern+0x64 00dfd474 00000001 00dfd478 00dfd48c // Looks like this thread is actually the one doing the driving: 0:013> kn # ChildEBP RetAddr 00 01dbe8a0 7c90daea ntdll!KiFastSystemCallRet 01 01dbe8a4 77e7cac1 ntdll!ZwRequestWaitReplyPort+0xc 02 01dbe8f0 77e7a33e rpcrt4!LRPC_CCALL::SendReceive+0x228 03 01dbe8fc 77e7a36f rpcrt4!I_RpcSendReceive+0x24 04 01dbe910 77ef4675 rpcrt4!NdrSendReceive+0x2b 05 01dbecec 7751620d rpcrt4!NdrClientCall2+0x222 06 01dbed00 775161c5 ole32!ServerAllocateOXIDAndOIDs+0x1b 07 01dbed54 77516117 ole32!CRpcResolver::ServerRegisterOXID+0x7d 08 01dbedac 7752c706 ole32!OXIDEntry::RegisterOXIDAndOIDs+0x38 09 01dbedc4 7752c6ac ole32!OXIDEntry::AllocOIDs+0x40 0a 01dbef34 77515e4a ole32!CComApartment::CallTheResolver+0x6b 0b 01dbef6c 77564d66 ole32!CComApartment::InitRemoting+0x1b7 0c 01dbef78 7750ba25 ole32!CComApartment::GetOXIDEntry+0x14 0d 01dbef8c 7750d83a ole32!GetLocalOXIDEntry+0x25 0e 01dbefa4 7750d97f ole32!ChkIfLocalOID+0x1e 0f 01dbefec 7752d8d4 ole32!FindStdMarshal+0x3e 10 01dbf02c 77525f55 ole32!UnmarshalObjRef+0x25 11 01dbf074 1654885b ole32!CGIPTable::GetInterfaceFromGlobal+0x115 WARNING: Stack unwind information not available. Following frames may be wrong. 12 01dbf1d8 1654b34c WpdShext+0x4885b 13 01dbf52c 1650dba4 WpdShext+0x4b34c 14 01dbf548 1650dba4 WpdShext+0xdba4 15 01dbf564 1650dba4 WpdShext+0xdba4 16 01dbf580 1650f516 WpdShext+0xdba4 17 01dbf6f8 1652325f WpdShext+0xf516 18 01dbff50 77f76f82 WpdShext+0x2325f 19 01dbffb4 7c80b729 shlwapi!WrapperThreadProc+0x94 1a 01dbffec 00000000 kernel32!BaseThreadStart+0x37 // BCToolbar is old, but the WMP Extension is the latest I can find: 0:004> lmvm BCToolbar start end module name 00f70000 00f95000 BCToolbar C (export symbols) BCToolbar.dll Loaded symbol image file: BCToolbar.dll Image path: C:\Program Files\Minimalist\Explorer Breadcrumbs\BCToolbar.dll Image name: BCToolbar.dll Timestamp: Wed Apr 04 11:59:39 2007 (4613CB6B) CheckSum: 00000000 ImageSize: 00025000 File version: 1.3.0.1 Product version: 1.3.0.1 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04e3 CompanyName: Minimalist ProductName: Minimalist Explorer Breadcrumbs InternalName: BCToolbar.dll OriginalFilename: BCToolbar.dll ProductVersion: 1.3.0.1 FileVersion: 1.3.0.1 FileDescription: Minimalist Explorer Breadcrumbs LegalCopyright: (c) 2006 Minimalist. All rights reserved. 0:004> lmvm WpdShext start end module name 16500000 1677e000 WpdShext (export symbols) WpdShext.dll Loaded symbol image file: WpdShext.dll Image path: C:\WINDOWS\system32\WpdShext.dll Image name: WpdShext.dll Timestamp: Fri Jan 30 23:37:12 2009 (4983D578) CheckSum: 0027C971 ImageSize: 0027E000 File version: 5.2.5721.5262 Product version: 5.2.5721.5262 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: wpdshext OriginalFilename: wpdshext.dll ProductVersion: 5.2.5721.5262 FileVersion: 5.2.5721.5262 (WMP_11.090130-1421) FileDescription: Portable Devices Shell Extension LegalCopyright: © Microsoft Corporation. All rights reserved. Again, given what we have it's really hard to say who caused the addresses to be busted (it is heap corruption, so we didn't catch the problem, we just catch the crash some time later when we go back to access the heap that's been corrupted). I'd say it's more likely it's the Minimalist shell extension, but without removing it it'll be hard to prove anything without enabling pageheap via gflags. I am going to suggest removal of the Minimalist shell extension as a troubleshooting step, and see if these issues don't go away.

Right, but what I'm trying to figure out is what it's not doing - is it that the printer doesn't stand by, or doesn't turn off all the way?

As to the video card problem, I had similar issues with an ATI Radeon 3650 for months, until I replaced the card (drivers were the same, replaced it with another 3650) and the problem magically went away. It would restart at the welcome screen, or on resuming from sleep. I thought it was the drivers, but obviously the hardware was bad (replaced via RMA, new card as I mentioned works fine).

So the printer does not go to standby after a set period of time (I'm assuming the green power light will switch to orange, or flash, or something)?