cluberti

C:\Windows\System32\cmd.exe /k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f Reboot, and viola - UAC off.

Happy birthday "old man" !

Yes, in the same way Vista SP1 and Server 2008 (RTM == SP1) are the same code.

Just because you have the latest drivers doesn't mean they're working properly . Does the issue reproduce when using safe mode, or safe mode w/networking?

Any possibilities that this is rundLL32.exe (capitalizations for clarity), not rundii32? Can you post a screenshot of the Comodo dialog box?

Win7 should be a better performer than Vista, although I doubt we'll see huge performance gains (just like XP over 2000 wasn't huge, nor was 2000 over NT4). It should be much more efficient (great for those with laptops and netbooks) and should definitely run faster, but I don't know how noticeable it will be on Vista-era hardware and newer. Also, totally off-topic, but what happened to whole words and punctuation in sentences? I think Shakespeare must be rolling in his grave anytime someone uses "TXT" or 1337-speek over, you know, actual whole words. <sigh>.

That would indicate then it's a driver, most likely.

Well, a 403.7 from an IIS server means 403.7 - Client certificate required Which would indicate the directory being requested is configured for certificate auth security, and the client making the request did not provide one at the time of the request (might be an error, but it just may have been the first anon request, in which case a 403.7 is an expected response to tell the client that it needs to provide a cert on the next request). http://support.microsoft.com/kb/942067/

Unfortunately, it costs a good amount of money to keep someone on the payroll (or some group of people) who still have access to and knowledge of the 9x and NT4 codebase. It costs tens of thousands of dollars to write, test, and package a hotfix for issues on these platforms, so yes, only customers willing to pay a somewhat exhorbitant fee for a hotfix for a platform that is out of support (and heck the 9x codebase is no longer even maintained) will get one. Also, redist of Microsoft code is strictly forbidden, so if you guys want to do this on your own outside MSFN, I can't stop you, but we won't discuss it here as per forum rules. Thread closed.

Well, I was hoping for a complete dump file, as a minidump in this case is fairly useless (I need the memory addresses and loaded module lists, which are not captured in a minidump - there is a reason the instructions I mentioned were for a *complete* memory dump). However, I've seen this particular callstack before: 0: kd> !thread GetPointerFromAddress: unable to read from 80562134 THREAD 898f8da8 Cid 0240.0288 Teb: 7ffd7000 Win32Thread: e21bc490 RUNNING on processor 0 IRP List: Unable to read nt!_IRP @ 89423b40 Not impersonating GetUlongFromAddress: unable to read from 805621cc Owning Process 89b27568 Image: lsass.exe Attached Process N/A Image: N/A ffdf0000: Unable to get shared data Wait Start TickCount 9621 Context Switch Count 1914 LargeStack ReadMemory error: Cannot get nt!KeMaximumIncrement value. UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address 0x77e56c7d Start Address 0x7c8106e9 Stack Init a8b0d000 Current a8b0c860 Base a8b0d000 Limit a8b09000 Call 0 Priority 9 BasePriority 9 PriorityDecrement 0 DecrementCount 16 ChildEBP RetAddr Args to Child a8b0c404 8051af5d c0e0003c 898f8da8 00000000 nt!MiLocateAndReserveWsle+0x51 (FPO: [Non-Fpo]) a8b0c458 804e2480 c6e34000 00000000 a8b0c584 nt!MmCheckCachedPageState+0x4ed (FPO: [Non-Fpo]) a8b0c4a0 804e3f0a 89ba0008 a8b0c4e0 00001000 nt!CcMapAndRead+0x86 (FPO: [Non-Fpo]) a8b0c534 8056a5ab 89ba7258 a8b0c574 00001000 nt!CcPinFileData+0x204 (FPO: [Non-Fpo]) a8b0c5a8 b9e67bc3 89ba7258 a8b0c5e8 00001000 nt!CcPreparePinWrite+0x93 (FPO: [Non-Fpo]) a8b0c628 b9e67d21 e13da830 e100fb50 00000028 Ntfs!LfsGetLbcb+0x5b (FPO: [Non-Fpo]) a8b0c63c b9e679a2 e13da830 00000010 e100fb50 Ntfs!LfsPrepareLfcbForLogRecord+0x4a (FPO: [Non-Fpo]) a8b0c66c b9e676d6 e13da830 e100fb50 00000001 Ntfs!LfsWriteLogRecordIntoLogPage+0x5c (FPO: [Non-Fpo]) a8b0c748 b9e671ff e100fb50 00000001 a8b0c808 Ntfs!LfsWrite+0x2f7 (FPO: [Non-Fpo]) a8b0c8cc b9e6759a 89ae3a40 89b9b320 00000000 Ntfs!NtfsWriteLog+0x6a2 (FPO: [Non-Fpo]) a8b0c92c b9e70ffc 89ae3a40 e15d3988 e15d3a50 Ntfs!NtfsCommitCurrentTransaction+0x197 (FPO: [Non-Fpo]) a8b0c940 b9e71f46 89ae3a40 89ae3a40 e15d3a50 Ntfs!NtfsCheckpointCurrentTransaction+0x21 (FPO: [Non-Fpo]) a8b0ca14 b9e71d6b 89ae3a40 898fc6f0 89423b40 Ntfs!NtfsSetEndOfFileInfo+0x5ec (FPO: [Non-Fpo]) a8b0ca84 b9e49b3b 89ae3a40 89423b40 898fc6f0 Ntfs!NtfsCommonSetInformation+0x477 (FPO: [Non-Fpo]) a8b0caec 804ef19f 89ba5020 89423b40 89423b50 Ntfs!NtfsFsdSetInformation+0xa3 (FPO: [Non-Fpo]) a8b0cafc 8057b543 a8b0cba0 a8b0cc2c 8057b010 nt!IopfCallDriver+0x31 (FPO: [0,0,0]) a8b0cb84 8054162c 80000638 a8b0cc38 a8b0cc48 nt!NtSetInformationFile+0x533 (FPO: [Non-Fpo]) a8b0cb84 80500ecd 80000638 a8b0cc38 a8b0cc48 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a8b0cba0) a8b0cc10 8063bffa 80000638 a8b0cc38 a8b0cc48 nt!ZwSetInformationFile+0x11 (FPO: [5,0,0]) a8b0cc50 8063b454 e150b700 00000001 00000400 nt!CmpDoFileSetSize+0x5e (FPO: [Non-Fpo]) a8b0ccd8 8063b8ce e150b758 00000000 e150b758 nt!HvpDoWriteHive+0x42a (FPO: [Non-Fpo]) a8b0ccf0 80632a96 e150b701 e13dd5c8 00000000 nt!HvSyncHive+0x88 (FPO: [Non-Fpo]) a8b0cd04 8062452e e150b758 00000120 a8b0cd64 nt!CmFlushKey+0x94 (FPO: [Non-Fpo]) a8b0cd58 8054162c 000000fc 00a8f770 7c91e4f4 nt!NtFlushKey+0x88 (FPO: [Non-Fpo]) a8b0cd58 7c91e4f4 000000fc 00a8f770 7c91e4f4 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a8b0cd64) WARNING: Frame IP not in any known module. Following frames may be wrong. 00a8f770 00000000 00000000 00000000 00000000 0x7c91e4f4 I've not seen this dump in a while, but knowing what is happening here, it appears to be memory corruption. So, either it's a device driver on the system, or you have faulty memory on the system (RAM, L2 CPU Cache, or Video RAM). I don't see us working in win32k.sys, so no GDI is being used, so that probably rules out the video card or driver. That leaves either your system's disk chipset driver, or the RAM or CPU cache as problematic. I'd start checking your RAM with memtest86 though, as a first.

No, I don't need the !analyze -v output, I need the .dmp file .

Configure the system for a complete dump file, then reboot. The next time the machine crashes, you should have a memory.dmp file in %windir%\ on the system. That can be looked at to see what's happening.

Sure I can .

If you're a total non-gamer, the 3xxx series of cards should be more than sufficient, and much cheaper. If you do need the additional fill rate (the 48xx cards are much beefier than the 3xxx cards in this respect), you're right to wait. I'm running 3650s in my two newer rigs, one for daily use and one for my MCE, and both are more than enough to handle what they're used for (HD video, MCE tasks, and the occasional game of tinker).

In looking at the dump file, it looks like Outlook has a hung RPC thread talking to an out-of-process COM server. Since this is HTML email, I'd say it's actually more likely that the problem exists in Word (or a Word add-on) than inside Outlook itself, although the error manifests itself in Outlook when using Word as the HTML editor. It *could* be the Mcafee hooks into Outlook (it is loading itself in most threads as a pass-through driver), but I don't see any direct evidence of this. 0:017> ~16kb ChildEBP RetAddr Args to Child 0626fea8 7c90e31b 7c80a746 0000006c 0626ff00 ntdll!KiFastSystemCallRet 0626feac 7c80a746 0000006c 0626ff00 0626fef0 ntdll!NtRemoveIoCompletion+0xc 0626fed8 77e770d8 0000006c 0626ff10 0626ff00 kernel32!GetQueuedCompletionStatus+0x29 0626ff14 77e7721c 00007530 0626ff6c 0626ff70 rpcrt4!COMMON_ProcessCalls+0xa1 0626ff80 77e772a4 0626ffa8 77e76a4d 001586d8 rpcrt4!LOADABLE_TRANSPORT::ProcessIOEvents+0xef 0626ff88 77e76a4d 001586d8 0015fc58 0191fc80 rpcrt4!ProcessIOEventsWrapper+0xd 0626ffa8 77e76c13 00157ed8 0626ffec 7c80b683 rpcrt4!BaseCachedThreadRoutine+0x79 0626ffb4 7c80b683 001bd8b0 0015fc58 0191fc80 rpcrt4!ThreadStartRoutine+0x1a 0626ffec 00000000 77e76bf9 001bd8b0 00000000 kernel32!BaseThreadStart+0x37 0:016> !dx CACHED_THREAD 00157ed8 +0x000 Next : 0x00158020 CACHED_THREAD +0x004 Previous : 0xffffffff CACHED_THREAD +0x008 Procedure : (null) +0x00c Parameter : (null) +0x010 OwningRpcServer : (null) +0x014 WorkAvailableFlag : 0 ( WorkIsNotAvailable ) +0x018 WaitForWorkEvent : TIMER 0:016> !dx THREAD 001bd8b0 =77e70000 CallDestroyedWithOutstandingLocks : 0x905a4d =77e70000 CallCancelled : 0x905a4d =77e70000 Yielded : 0x905a4d +0x000 fAsync : 0 +0x004 CancelTimeout : -1 +0x008 HandleToThread : 0x00000b3c +0x00c ThreadEvent : EVENT +0x010 Context : (null) +0x014 SecurityContext : (null) +0x018 BufferCache : [4] BCACHE_STATE +0x038 ExtendedStatus : 0 +0x03c DebugCellTag : 0 +0x040 DebugCell : (null) +0x044 SavedProcedure : 0x77e769fa int rpcrt4!BaseCachedThreadRoutine+0 +0x048 SavedParameter : 0x001c88c0 +0x04c ActiveCall : (null) +0x050 ThreadEEInfo : (null) +0x054 NDRSlot : (null) +0x058 NDRSlot2 : (null) +0x05c CachedLrpcCall : (null) +0x060 Flags : CompositeFlags +0x064 LastSuccessfullyDestroyedContext : (null) +0x068 CachedWaiterPtr : (null) +0x06c CachedWaiter : SWMRWaiter +0x07c CachedEEInfoBlock : (null) +0x080 ParametersOfCachedEEInfo : 0 Handle 00000b3c Type Thread Attributes 0 GrantedAccess 0x1f03ff: Delete,ReadControl,WriteDac,WriteOwner,Synch Terminate,Suspend,Alert,GetContext,SetContext,SetInfo,QueryInfo,SetToken,Impersonate,DirectImpersona te HandleCount 7 PointerCount 9 Name <none> 0:016> !dx 0x00158440 DLL +0x000 DllHandle : (null) 0:016> !address 00158440 00150000 : 00150000 - 00095000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageHeap Handle 00150000 You might be better off disabling word as the Outlook default email editor, and see if that removes the problem. I'd say an uninstall of Microsoft Word and a reinstall is also a good thing at this point too.

There are lots of filehosting companies, some free.

Considering the .dmp file is the file containing most of the data I need, yes .

You can also do it pretty easily with a standard WIM file, the WAIK, extracted driver files (*.inf, *.sys, etc), and an elevated WAIK command prompt. Use imagex to mount the wim file (imagex /mountrw <drive:\path\to\image.wim> <image number inside WIM to modify> <drive:\path\to\mount\folder>), use peimg to inject the drivers (peimg /inf <drive:\path\to\driver\.infs> /image=<drive:\path\to\mount\folder>), then imagex to commit the changes (imagex /unmount /commit <drive:\path\to\mount\folder>). Note that this works on both PE boot.wim files and Vista/2008 image.wim files.

Normally I disagree with you on tweaks, but this one is a good one if you have a system that's heavily loaded. 10 hex is the max (giving you 16 additional threads on top of the 10 already devoted to these tasks), although that will cause some excess thread memory usage as these will sit fallow for long periods of time. You would be best to try starting at 6, and working your way upwards until performance meets your needs. Unless you've got the kernel VA to spare, of course, in which case 10 is a perfectly fine number.

No, I do not find it confusing. It's in the personal message dialog area, not the member group area, and as such it's just a joke (and a funny one at that). Just like my personal message in that location says "Gustatus Similis Pullus". If you know any Latin, it's not confusing either.

Win7 runs *better* on the same hardware as Vista - even 1GB. I still wouldn't run with 512MB, but for a home-user type machine, Win7 runs fine on 1GB of RAM.

if you're using 6.x of the mstsc binary, try the /admin switch instead.

According to the script, outlook wasn't running when you ran the command: The following requested processes are not executing: OUTLOOK.EXE; Get the error on screen, then run the command.

If only Microsoft sites are affected, then either your ISP's DNS servers (which they provide to you when giving you an IP address) are busted, or you've got something on your machine actively affecting DNS queries for microsoft addresses. Since an app doing this would most definitely be a virus or some other malware, a hijackthis log might bring to light any possible malware causes - you'd need a good virus scanner to rule out viruses.

No, more likely that the print server's auth is coming across in a way Vista isn't dealing with properly (or vice versa). You should first find out what auth is being used on the xprint server, and maybe a network trace to see if there are any auth failures over the wire that you can see to start troubleshooting. It is true though, Vista and IPP on *nix print servers do have troubles that XP did not, and most of them come down to auth differences. Especially on domains.