cluberti

I'd start by making sure that Word was not set as the default email editor, and after that I'd probably suggest adplus dumps of Outlook when "hung" to see what's happening inside the process.

Working set, virtual bytes, or private bytes?

Unless you downloaded Vista from a Microsoft licensing site, this would be against forum rules. And if you had gotten it from an Open or eOpen or MSDN, your DVD .iso would be bootable, so I suspect perhaps this is a bootleg copy. Consider yourself warned.

If you're talking about Active Directory, no, there's no way to log on as a user or impersonate a user without knowing the password, even as an Admin. I'm a little confused as to what you're trying to do and why, and why you would need the password. Care to elaborate a bit?

If they're both configured unicast, and you of course have two network interfaces configured for the nlb cluster, the only other thing it could possibly be would be the metric on the interface itself, or the switch(es) the machines are attached to.

Did you configure these servers in unicast or multicast mode?

Why are you having to reinstall XP on that many PCs at once?

Since Vista and XP profiles are entirely incompatible, the only way to get the profiles to share the documents folder is to do folder redirection for the shell folders you need shared.

The WebClient service is there to facilitate WebDAV browsing, and if you aren't doing anything with WebDAV you can safely disable the service. Note, however, that installing Office installs another WebDAV redirector (which you can disable in Office XP/2003, but not Office 2007). Usually you'll see temporary WebDAV files when you visit an IIS site with FP Extensions enabled (used or not).

The only way to get something more XP-like is to install a defrag program.

Would you be able to dump the box the next time it hangs? http://www.msfn.org/board/Creating_memory_dumps_t90244.html

Any updates, moo2004?

Someone at work happened to have one of those in his box, and we were able to install 158.24 (June 1st) on Vista RTM x86 no problem. Did you ever have pre-release drivers on the box, perhaps?

Dell Dimension 9200 at work with an Intel dual-core, ATI graphics, and 4GB of RAM, and the laptop is a Lenovo T60p with an Intel dual-core, ATI graphics, and 4GB of RAM, and both are running Vista Ultimate x64.

Who ever thought they would see the day that something like this was said

I can't speak to specifics, but what happens in general terms is that when you install Windows, a hardware hash and an installation ID is generated. When you enter your PID and activate, the Vista machine and the activation servers store the hash based on an already stored hardware hash, the PID and the installation ID, as well as mark that PID "activated". - If there is an attempt to reactivate an already activated PID before a specified time has passed since the PID was first activated, and the machine associated with that PID has not checked in for a specific number of re-validations (I believe it's 3 or 4 missed re-checks, or 2 years approximately), activation will fail. - If there is an attempt to move an activated copy onto another box (imaging, changing out too many parts, etc), the system hash will not match the hash previously stored and activated, and if the hash differs greatly the box will need to be reactivated. You can reactivate an already-activated Vista PID on a second machine if you call the clearinghouse 800# and go through the phone activation, and theoretically you could have 2 (or more) machines activated concurrently on the same PID. The fun begins when those machines all check in to reactivate (I think the timeframe is every 180 days) - if the servers work as I understand them to be designed, all but 1 of those machines will fail reactivation thus limiting this practice's effectiveness. Re-checking was not done on XP or 2003, so if you managed to activate multiple machines against one PID, they would work indefinitely.

Note that the local Administrator account is the _only_ account on the box that has a full access token when UAC is enabled - even other local admin and domain admin accounts will run with a limited user token. From the symptoms you state, it sounds like your application is doing something bad (at least in UAC terms) and until you "run as administrator" the application, or get a version that doesn't have the issue, or disable UAC, this will happen.

I agree - does it happen in safe mode w/ networking, and also, if you disable one or the other adapter (try disabling each, one at a time and reboot), does the issue occur? This sounds like a driver issue, honestly, because if it were a Vista issue we'd (for sure!) be hearing more about this one.

Are we sure it's a bug, or is it that there are still open handles (or pointers to now invalid handles) that is keeping the folder itself "locked" until a reboot (when the handles would be closed, of course)? I'd prefer a Process Explorer output, or a full dump of the box in state, before jumping to conclusions.

Usually this occurs when a user is unable to unload their profile, and thus the user stays "logged on" because the logout did not completely finish. You can see if this is the case by looking at the system remotely using TS admin or pslist, and you're likely to see two users fully logged on, or possibly one fully logged on with another "orphaned" profile with only winlogon and a few other processes listed. Since a Windows desktop OS cannot have more than one active logon session, the second logon does not work. The bogus password error I do not understand, although it is possible that there is some problem with winlogon or schannel on the box causing the error once the problem state is reached. The best "fix" for this is to make sure you aren't using bad antivirus or printer software/drivers that leave file or registry handles open, or do not clean up pointers to handles when a user issues a logout request, and also to have the latest release version of UPHClean installed on the box to make sure registry handles are cleaned up for sure on logout (it won't kill file handles or pointers to file handles, as that could corrupt files - that might keep profiles loaded, but at least files won't go bad due to logging out).

Giving a local computer account access only affects the LocalSystem account on the machine, not the logged-on user (they're two different tokens) - so unless you're accessing resources on behalf of the LocalSystem account (and from inference of the question you're asking, you aren't), it won't do what you want it to do. You either assign a user permissions to a resource, or you don't. There aren't any conditional settings, either they have access or they do not. The real question is why you want to do this in the first place, because there may be a way to do what you want, if we know what it is you're really after.

This was what application center 2000 was written to do (cluster COM/DCOM applications, especially COM web apps), but it's no longer a mainstream product and was made no longer available for procurement as of October 2006. However, with System Center 2007 and Windows Server 2008, AppCenter's functionality will be replicated (and hopefully improved upon). You can't cluster COM applications, so there's not a really good way to do this without App Center 2000 SP2 (or wait for Server 2008 and System Center 2007). Note that you'll likely have to make sure you consider migrating to a .NET version of your app for it to work properly with System Center 2007 and Server 2008).

If it was compiled /largeaddressaware, then it can actually use 3GB on an x86 box (with /3gb in the boot.ini) or 4GB on an x64 box. There's many a reason why 32bit drivers aren't supported or recommended on x64, and this is one of them.

Sorry - should have pointed this out in my initial request.

Here's what is happening, according to the dr watson dump you attached: This thread has created a critical section to do whatever the TDSHELL binary requests here (can't tell, as there's no symbols or export functions in the .dll): 0:003> kn # ChildEBP RetAddr 00 00ffe98c 7c90e9c0 ntdll!KiFastSystemCallRet 01 00ffe990 7c8025cb ntdll!ZwWaitForSingleObject+0xc 02 00ffe9f4 7c802532 kernel32!WaitForSingleObjectEx+0xa8 03 00ffea08 00cca3b7 kernel32!WaitForSingleObject+0x12 04 00fff714 7e41f84a TDSHELL+0x3a3b7 05 00fff730 7e4563be user32!DispatchHookW+0x31 06 00fff75c 7e41b50c user32!fnHkINLPCWPRETSTRUCTW+0x5e 07 00fff784 7c90eae3 user32!__fnDWORD+0x24 08 00fff7a8 7e4194be ntdll!KiUserCallbackDispatcher+0x13 09 00fff7e4 7e41b903 user32!NtUserMessageCall+0xc 0a 00fff804 0100761e user32!SendMessageW+0x7f 0b 00fff83c 010075d9 explorer!CTrayItemManager::GetItemData+0x3c 0c 00fff850 010075a7 explorer!CTrayItemManager::GetItemDataByIndex+0x12 0d 00fff864 0100785f explorer!CTrayItemManager::FindItemAssociatedWithHwndUid+0x1e 0e 00fff88c 01007808 explorer!CTrayNotify::_TrayNotifyIcon+0x6b 0f 00fff89c 010077bc explorer!CTrayNotify::TrayNotify+0x33 10 00fff960 01001b5e explorer!CTray::v_WndProc+0x510 11 00fff984 7e418734 explorer!CImpWndProc::s_WndProc+0x65 12 00fff9b0 7e418816 user32!InternalCallWinProc+0x28 13 00fffa18 7e41b4c0 user32!UserCallWinProcCheckWow+0x150 14 00fffa6c 7e42e3b4 user32!DispatchClientMessage+0xa3 15 00fffa9c 7c90eae3 user32!__fnCOPYDATA+0x41 16 00fffea8 7e4193e9 ntdll!KiUserCallbackDispatcher+0x13 17 00fffed4 7e419402 user32!NtUserPeekMessage+0xc 18 00ffff00 010019c1 user32!PeekMessageW+0xbc 19 00ffff44 01011e8b explorer!CTray::_MessageLoop+0x24 1a 00ffff50 77f7429a explorer!CTray::MainThreadProc+0x29 1b 00ffffb4 7c80b683 shlwapi!WrapperThreadProc+0x94 1c 00ffffec 00000000 kernel32!BaseThreadStart+0x37 This thread is working on that critical section, and access violates writing to a particular virtual memory address: 0:005> kn # ChildEBP RetAddr 00 0117fe7c 7c90104b ntdll!RtlpWaitForCriticalSection+0x8c 01 0117fe84 75f81ba7 ntdll!RtlEnterCriticalSection+0x46 02 0117fee0 77f69498 browseui!CShellTaskScheduler_ThreadProc+0x11e 03 0117fef8 7c927545 shlwapi!ExecuteWorkItem+0x1d 04 0117ff40 7c927583 ntdll!RtlpWorkerCallout+0x70 05 0117ff60 7c927645 ntdll!RtlpExecuteWorkerRequest+0x1a 06 0117ff74 7c92761c ntdll!RtlpApcCallout+0x11 07 0117ffb4 7c80b683 ntdll!RtlpWorkerThread+0x87 08 0117ffec 00000000 kernel32!BaseThreadStart+0x37 The eip register for this thread points to 7c918fea, which happens to be the critical section we've started waiting on. The critical section we're waiting on looks like this (it's bogus, btw, it shouldn't look like this): 0:005> !critsec 7c918fea DebugInfo for CritSec at 7c918fea could not be read Probably NOT an initialized critical section. CritSec ntdll!RtlpWaitForCriticalSection+8c at 7c918fea LockCount -528221115 RecursionCount -398096127 OwningThread 40ff068b *** Locked The exception record for this thread looks like this: EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 7c918fea (ntdll!RtlpWaitForCriticalSection+0x0000008c) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 0065005c Parameter 1 is most important, because it's the memory address we failed to write to - in this case 0065005c. You'll notice that's the ds register for the critsec thread as well, but that it is also likely invalid: 0:003> ~5s eax=0065004c ebx=00000000 ecx=00000000 edx=01d45d3c esi=01d45d3c edi=00000000 eip=7c918fea esp=0117fe08 ebp=0117fe7c iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 ntdll!RtlpWaitForCriticalSection+0x8c: 7c918fea ff4010 inc dword ptr [eax+10h] ds:0023:0065005c=???????? I don't know for sure what is causing this, but it looks like one of three things - tdshell.dll, deskbar.dll, and possibly browseui or shlwapi.dll. The tdshell.dll binary looks like this: 0:005> lmvm tdshell start end module name 00c90000 00dfd000 TDSHELL Loaded symbol image file: TDSHELL.DLL Image path: C:\WINDOWS\system32\TDSHELL.DLL Image name: TDSHELL.DLL Timestamp: Thu Jul 27 08:41:03 2006 (44C8B45F) CheckSum: 00000000 ImageSize: 0016D000 File version: 4.4.82.17 Product version: 4.4.82.17 File flags: 28 (Mask 3F) Private Special File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 I'm not sure who owns this .dll, but I believe it's from TeamStream, which is a voice application vendor for gamers. The deskbar.dll looks like this: 0:005> lmvm deskbar start end module name 01420000 014b2000 deskbar Loaded symbol image file: deskbar.dll Image path: C:\Program Files\Windows Desktop Search\deskbar.dll Image name: deskbar.dll Timestamp: Mon Feb 05 18:40:31 2007 (45C7C06F) CheckSum: 000912C8 ImageSize: 00092000 File version: 6.0.6000.16431 Product version: 6.0.6000.16431 File flags: 8 (Mask 3F) Private File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 This is of course the Windows desktop search .dll, which loads the "search" option in the taskbar. Browseui and Shlwapi look like this: 0:005> lmvm browseui start end module name 75f80000 7607d000 browseui Loaded symbol image file: browseui.dll Image path: C:\WINDOWS\system32\browseui.dll Image name: browseui.dll Timestamp: Tue Feb 20 04:48:02 2007 (45DAC3D2) CheckSum: 000FD3A7 ImageSize: 000FD000 File version: 6.0.2900.3086 Product version: 6.0.2900.3086 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 0:005> lmvm shlwapi start end module name 77f60000 77fd6000 shlwapi Loaded symbol image file: shlwapi.dll Image path: C:\WINDOWS\system32\shlwapi.dll Image name: shlwapi.dll Timestamp: Tue Feb 20 04:48:10 2007 (45DAC3DA) CheckSum: 00080FD2 ImageSize: 00076000 File version: 6.0.2900.3086 Product version: 6.0.2900.3086 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 It looks like you have the February cumulative update for IE installed (MS07-027) - did you install the QFE build for this update, perhaps? I'd say the next step is to remove desktop search and the TeamStream software, if possible, and see what happens - someone or something is causing corruption in the stack, which ultimately corrupts the registers stored, and causes the access violation. I'm sure that ds value should have been something valid, but it's not anymore due to corruption somewhere along the line; the eip register was probably meant to point to something valid as well, but currently does not point to a valid critical section address. I can't say with 100% certainty that it's one of those .dlls I've mentioned, but it looks like they're involved.