2006-09-29

Windows Vista and Protected Processes

On WHDC, Microsoft has a document entitled "Protected Processes in Windows Vista". While I'm not yet living in Vista-land (though I do visit at least weekly), I don't have my head buried in the sand, either. But I can honestly say that this is the first I've heard about this new type of process introduced in Vista. The new type of process was created "to enhance support for digital rights management functionality in Windows Vista". Heh heh. Seems a bit interesting that DRM is specified as the the driving force behind this.

Anyway, the paper outlines what one can and cannot do with protected processes (from the perspective of utility software that does process reporting and other interaction with processes running on the system). There's really only 3 pages of meat in the document, but it seems like a good overview.

The paper states that "...due to the restrictions of running inside a protected process, the operating system requires that these processes be specially signed". That's a good thing... Imagine malware running as a protected process. Blech.

I'm probably being too literal here, but does the process need to be signed, or is it the binary image on disk that needs to be signed? And what is meant by "specially signed"? Is that something different from the standard implied meaning?

And that statement makes me wonder further - there are restrictions on running inside a protected process? The paper also states that the "primary difference between a typical process and a protected process is the level of access that other processes in the system can obtain to protected processes". This seems contrary to the previous statement. However since the paper is about interacting with protected processes, rather than restrictions that may be imposed upon code running in the context of a protected process, the answers will have to come from elsewhere.

Protected process can pose a "problem if memory scanning is critical to the operation of the application [that wishes to interact with protected processes]". Should be interesting to see how vendors of AV and other security software deal with this new class of process.

Another blurb at the bottom of the document caught my attention...


Do not attempt to circumvent this restriction by installing a kernel-mode component to access the memory of a protected process because the system and third-party applications may rely on the fact that protected processes are signed code that is run in a contained environment.
What? I'm ignorant. What does this mean: "may rely on the fact that protected processes...run in a contained environment". What happens if a kernel-mode component plays with "the memory of a protected process"? Nothing may happen now, but it could break things later? If anyone would care to provide clarification, I would appreciate it.

Also Channel 9 has a video on Process Management in Windows Vista which I have yet to find time to watch. The summary states:
Vista introduces a new type of process called a protected process. What are "protected processes"? How do they work?
I suspect that at least some of my questions will be answered there.

Doesn't look like Process Explorer yet detects / identifies protected processes. The feature isn't listed on the program page, and searches don't turn up much:
Google Search
Google Groups Search
Sysinternals Forums Search

2006-09-19

0x8ddd0009 with Microsoft Update / Windows Update Redux: More fixes / workarounds...

[Added 2006-10-15: Another potential fix here...]

In addition to the potential solutions posted here, here, and here, the following are some additional things to try when battling the dreaded 0x8ddd0009 error from Windows Update / Microsoft Update. These suggestions come from comments that others have posted to the aforementioned blog entires, as well as new ideas compiled from various community discussions.

In many cases, update sessions that ultimately result in the 0x8ddd0009 error cause high CPU utilization prior to erroring out. There is suspicion that on older hardware, this can cause "time outs" or other undesirable quirks with the Windows Update / Microsoft Update services / websites. Presumably, pruning some of the applications and services that are running prior to attempting to use Windows Update / Microsoft Update can help in this. Disabling antivirus applications in particular (read on) seems to help. It may be that rebooting the system, exiting as many applications as possible (including those running in the systray, by the clock) when the system comes back up, and then stopping unnecessary services(*) before trying Windows Update / Microsoft Update will do the trick for some people.
* - Of course, it helps to know what services are necessary and what services are merely "nice to have". The following may be of some assistance in determining this. Note that I have NOT reviewed these links; I encountered them when trying to determine what happened to BlackViper's site (blackviper.com); appears he forgot to pay his domain name registration fee and lost it... You may have some luck with Archive.org's archives of the site... Anyway, on to the links:
Services Guide for Windows XP
Windows XP Services Tweak Guide
Windows 2000 Services Tweak guide


One person reported that uninstalling the .NET Framework 2.0 and rebooting took care of the problem.

Another reported that registering / re-registering various components did the trick. The following can be executed from a Command Prompt (Start -> Run -> CMD.EXE):
net stop wuauserv
regsvr32 wuapi.dll
regsvr32 wups.dll
regsvr32 wuaueng.dll
regsvr32 wuaueng1.dll
regsvr32 wucltui.dll
regsvr32 wuweb.dll
regsvr32 MSXML3.dll
regsvr32 qmgr.dll
regsvr32 qmgrprxy.dll
regsvr32 jscript.dll
net start wuauserv

Someone else backed off some of the changes recently introduced to a system, and that enabled Windows Update / Microsoft Update to run successfully - changing the resolution back to 800x600 from 1024x768, and disabling the real-time scanning function of the newly installed anti-virus software did the trick. No word on what AV software was involved...

Another person reported that shutting down services related to McAfee antivirus and using the "Custom" update feature on Microsoft Update enabled him to successfully update his system.

Selectively installing larger items (OS Service Packs, IE, .NET Framework, DirectX, etc) outside of Windows Update / Microsoft Update, and coming back to the Windows Update / Microsoft Update services for the smaller patches worked for another individual.

Hope this update provides additional things to try for those that have tried the things listed here, here, and here.

2006-09-10

SOFTWARE_NX_FAULT - ExceptionInformation[0] for 0xc0000005 can be 0, 1, or... 8?

Hmmm...

I noticed this when digging through the dump of an Outlook 2003 crash... EXCEPTION_RECORD.ExceptionInformation[0] for EXCEPTION_RECORD.ExceptionCode == EXCEPTION_ACCESS_VIOLATION can have a value other than 0 or 1... From the EXCEPTION_RECORD documentation:

If this value is 8, the thread causes a user-mode data execution prevention (DEP) violation.
From the Outlook crash dump:
EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 124132d5 (<mytilus.dll>+0x000132d5)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000008
Parameter[1]: 124132d5
Attempt to execute non-executable address 124132d5

DEFAULT_BUCKET_ID: SOFTWARE_NX_FAULT

2006-09-07

Blue Screen Of Death: 0x0000007E

Something happened the other day and I was quite surprised by it. I hadn't really noticed how long it had been since I'd experienced a BSOD until there it was, staring me in the face.
0x0000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED).
I wasn't doing anything special - the system wasn't starting up or shutting down, and I wasn't using any exotic hardware or software. Just a flash of the screen, and then FLOOP! BSOD.

I let KeBugCheckEx write out the kernel memory dump, and rebooted. SaveDump did its thing and I tossed Memory.DMP into WinDbg. I'm not very proficient with WinDbg, but WinDbg makes analyzing most crash dumps (that I've run across, at least) rather trivial.

!analyze -v


That's all you need to know.

For my BSOD, WinDbg told me that the likely culprit was HCMON.SYS, which (indirectly) caused an access violation (0xc0000005) when an attempt was made to write to 0x2dc22865.

A search of %windir%\system32\drivers shows that HCMON.SYS is a component of VMware Workstation (and likely VMware Player, and...). The Version Resource of HCMON.SYS indicates that it is the "VMware USB monitor". Of course, I had recently upgraded to VMware Workstation 5.5.2, which was released on 2006-08-10. The timestamp on HCMON.SYS was 2006-08-04.

I don't know if a problem was introduced in the new version of VMware Workstation, or if the fact that a VMware component was implicated in a BSOD that took place shortly after the component was upgraded is merely a coincidence, but it sure is nice to be able to identify the source of the BSOD. If it continues to be a problem, I know where to go...

2006-09-01

Cause of regular Outlook 2003 crash...

[2006-09-29: Related post here...]

Found out what was causing my Outlook crash today. MYTILUS.DLL, which happens to be the "Common Shell - Scanners' interface to the engine" part of Network Associates' McAfee VirusScan product, is regularly causing an access violation / SOFTWARE_NX_FAULT (Software-enforced no-execute / DEP fault).

Sigh. At least it only happens when I'm shutting Outlook down.