My Green Paste, Inc.

This post originally appeared on an external website

I had an interesting need the other day. I wanted to set up a test Windows Server 2003 box on a development system. I didn't have a license for VMware workstation that I could use on the development system, and I didn't want to install the free VMware Server since I've not yet had an opportunity to use it yet and this wasn't the time to start. VMware Player can only "play" (not create) virtual machines.

Virtual PC 2004 w/SP1 from Microsoft is now free. But I find that I prefer VMware's products to the Microsoft offerings. Not wanting to spend much time debating which virtualization package I should use, I went ahead and installed Virtual PC 2004 w/SP1. Whilst installing Windows Server 2003 Standard Edition into a virtual machine, I started wondering if VMware Player could interpret Virtual PC virtual machines.

The VMware Player product page states:

VMware Player also supports Microsoft virtual machines...

It wasn't a large jump to interpret "Microsoft virtual machines" as "Virtual PC 2004 virtual machines". Indeed, that is the case. I finished installing Windows Server 2003 in Virtual PC 2004, and powered the VM off just after the final reboot that takes place during installation. I installed VMware Player, ran it, opened the Virtual PC 2004 .VMC file, and after a short import process I was able to start the virtual machine that I had created with Virtual PC 2004, in VMware Player.

So, for $0 (well, a Windows OS license is required) I was able to create a Windows Server 2003 virtual machine with Virtual PC 2004 and use it with VMware Player. Pretty cool...

This post originally appeared on an external website

This post originally appeared on an external website

ZombifyActCtx

This post originally appeared on an external website

This post originally appeared on an external website

Windows Vista hates me. I've been wasting my time trying to get Vista beta 2 installed. I know, I know - "beta 2? That was released months ago!" But I've simply been too busy to install it even though I downloaded it when Microsoft opened up the Consumer Preview Program.

My first attempt at installing Vista was on a brand new hard drive. No partitions on it, no nothing. I booted the DVD I had burned the ISO to, and was greeted with a screen that looked like this:


Over and over and over and over again. The progress bar would complete, and the system would reboot, boot from the DVD, and go through the progress bar again. And again. And again. Ad nauseam. I suspected a bad burn so I burned another disc. Same result. I ultimately tried 7 discs (DVD-R, DVD+R, DVD-RW) using 3 different software packages and 3 different burners (no rhyme or reason to my selection process). Always had the same result.

I googled a bit and discovered that I wasn't the only one with the problem where "Windows is loading files..." would display on the screen with a progress bar and setup would reboot after the progress bar completed... and the problems were most often related to a bad burn or a a bad download. Sigh.

After making 2 backups, I tried upgrading XP Pro to beta 2, using one of the same discs. Setup begain, and I was prompted for some information. When the file copy process began, I left to go do some other things. Coming back to the system, I was greeted with an error:

An error occurred while copying setup files onto your local machine. Error code is 0x80070241.

I obtained access to another Vista beta 2 ISO image, burned it, and tried installing Vista. This time, the "Windows is loading files" screen looked a bit different - the font was different and there was a flashing white cursor at the end of the line with the progress bar:


I thought that was a bit strange. Once the progress bar completed, I was presented with an error message:

File: \windows\system32\winload.exe
Status: 0xc0000001
Info: The selected entry could not be loaded because the application is missing or corrupt

Once again, I tried buring with different media types, using different software and different hardware. Same results each time. I was trying to avoid using a VM to run Vista because I actually wanted to get some real-world, day-to-day experience with it. But at this point I broke out VMware and mounted the ISO. The virtual machine did the same thing as the "real" machine - the same error messages and problems with the ISO images. Looks like I'll have to wait until RC1 is released (hopefully sometime in early September) before I get a chance to install Vista...

This post originally appeared on an external website

This post originally appeared on an external website

1) Wrote a while back about "Protecting aginst Pointer Subterfuge". Michael Howard has updated the description of the algorithm used to encode pointers with EncodePointer/EncodeSystemPointer.

2) Previously, I pointed to an article on the Microsoft Driver site that details x64 Kernel Patch Protection. The Windows Vista Security blog has a higher-level description of kernel patching as well as some suggestions for alternatives.

This post originally appeared on an external website

[Added 2006-09-19: Additional things to try here...]

This post originally appeared on an external website

Microsoft just posted knowledge base article 924092 today - "You experience problems when you use a Microsoft update service".

The CAUSE section states:

These problems may occur because some of the Windows Update Agent 2.0 files are missing or corrupted. Windows Update Agent 2.0 is required to use these products and services.

This could be another way to fix the mysterious 0x8ddd0009 Windows Update / Microsoft Update error - intall the "Windows Update Agent 2.0" package.

This post originally appeared on an external website

This post originally appeared on an external website

Found the following Microsoft Knowledge Base article today:
You receive an error message when you try to send an e-mail message by using the System.Web.Mail namespace in the .NET Framework 1.0

The gist of the article is that one should not use:
SmtpMail.SmtpServer.Insert(0, "mail.mycompany.com");
to change the Smtp.SmtpServer property. Rather, one should use:
SmtpMail.SmtpServer = "mail.mycompany.com";

Really? I'll make a note.

Further, the CAUSE section is kind of bogus - it states:

This issue occurs because the String.Insert method does not change the value of the SmtpMail.SmtpServer property. Therefore, the value of the SmtpMail.SmtpServer property is null.

Now, my take on this is that the chances are pretty good that if a person is using the "problematic" method of setting SmtpServer, they might want to know WHY it is that "the String.Insert method does not change the value of the SmtpMail.SmtpServer property". (The answer, of course, is that String.Insert returns "a new String equivalent to this instance but with value inserted at position startIndex.")

At least the suggested resolution wasn't:
SmtpMail.SmtpServer = SmtpMail.SmtpServer.Insert(0, "mail.mycompany.com");

This type of problem, sadly, is probably rather common. I imagine that this type of thing happens all over the place. So why does this specific instance warrant a new article in the Microsoft knowledge base? I hope it doesn't mean that a bug resulting from the code depicted in 922777 was discovered in a Microsoft product...

This post originally appeared on an external website

This post originally appeared on an external website

I was having significant performance problems on a Windows XP SP2 laptop - the system was performing at 25% - 50% of its regular ability. So I pushed the "Turbo" button on the front, and that took care of everything.

In 1994, maybe.

No such fix for my problem. It was getting rather unbearable. I wanted to point the finger at Norton / Symantec software, but I didn't have hours to spend uninstalling it so I had to endure. I noted that the performance degradation came into play when there was moderate to heavy disk I/O.

Finally, I had some time to troubleshoot the problem. Process Explorer was telling me that Interrupts were monopolizing the CPU - 75% - 80% at times! I hadn't installed any hardware recently, and it was happening when the laptop was docked and undocked. Event Viewer didn't have any pertinent information.

After some thought, I recalled my observation about the performance degradation coinciding with disk I/O. I suspected that somehow the IDE channel had been set to PIO mode rather than Ultra DMA Mode 5. Device Manager confirmed my suspicions. Something (Windows?) had modified the setting for the Primary IDE Channel without notifying me. I uninstalled the primary IDE channel, rebooted, and let Windows redetect the hardware. The setting was back to Ultra DMA Mode 5, and the system was back to performing as it should have.

Microsoft Knowledge Base article "IDE ATA and ATAPI disks use PIO mode after multiple time-out or CRC errors occur" may provide some insight into how the transfer mode setting on my system was changed, but I'm running SP2 from August 2004 with all updates, and ATAPI.SYS referenced in the KB article is from April 2003. And, there was nothing in Event Viewer from ATAPI indicating that there were time-out or CRC errors.

This post originally appeared on an external website

This post originally appeared on an external website

Previously, I had been considering techniques that would allow me to RDP into a system and still be able to use my U3 Flash drive. I didn't want to have to log into a session on the glass, and then plug in the password for the U3 Launch Pad program. I want to plug the drive into the system in my office, and be able to hit it when I want to. I'm lazy.

Ultimately, I chose to explore Detours from Microsoft Research to accomplish this. I'm happy to report a rather simple, if somewhat unelegant, success. I simply downloaded Detours Express 2.1, explored the documentation a bit, and played with the samples. In under 2 hours, I had accomplished what I had set out to do - essentially make ProcessIdToSessionId return the same thing as WTSGetActiveConsoleSessionId.

Two of the Detours samples ("WithDll" and "Simple") were used in my solution. WithDll was just what I needed to jumpstart the LaunchU3.exe process with the code I wanted to "inject" into the process, so I was able to use that sample with absolutely no modifications.

The "Simple" sample provided framework code that I simply adapted to do what I wanted. Again, I was looking to "replace" ProcessIdToSessionId's implementation with:
*pSessionId = WTSGetActiveConsoleSessionId();

The code at the bottom of this post uses Detours to help me do just that. The code was written in Visual Studio 2005 / VC++ 8.0, so some of the CRT functions are the "Secure (_s)" versions. I didn't go through and do the _CRT_INSECURE_DEPRECATE #ifdefs.

So anyway, this works great, but normally the LaunchU3.exe program runs automatically when the USB drive is plugged into a system - a small partition presents itself as a read-only drive formatted with the CDFS filesystem. That partition contains an AutoRun.inf instructing Windows to kick off LaunchU3.exe. But I need to run WithDll.exe from the Detours Express package, not LaunchU3.exe.

Sounded like a killer application for an image file hijack ala "Image File Execution Options: Good, Evil, Fun":
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LaunchU3.exe\Debugger = "<path to>\WithDll.exe /d:<path to>\MyDetoursDll.dll "

Note the space before the closing quote of the value - the Debugger gets passed the image name, so the command to WithDll.exe looks like:

<path to>\WithDll.exe /d:<path to>\MyDetoursDll.dll x:\LaunchU3.exe

The only problem is that we do actually want to launch the specified program (LaunchU3.exe). But running LaunchU3.exe will kick off WithDll.exe, which will start LaunchU3.exe, which will start WithDll.exe... There are a couple of options to deal with this. The easiest is to copy LaunchU3.exe from the USB drive onto the hard drive and give it a new name - this was the approach that I took. Then, specify the following as the Debugger command in Image File Execution Options:

<path to>\WithDll.exe /d:<path to>\MyDetoursDll.dll <path to>\MyLaunchU3.exe

Another way would be to turn WithDll into a debugger - change the flags that get passed to the Detours function "DetourCreateProcessWithDll" to specify "DEBUG_ONLY_THIS_PROCESS", and incorporate a dummy debugger loop into the application, something like:

    DEBUG_EVENT de = {0};
    for( ;; )
    {
        WaitForDebugEvent( &de, INFINITE );
        if( EXIT_PROCESS_DEBUG_EVENT == de.dwDebugEventCode ) break;
        ContinueDebugEvent( de.dwProcessId, de.dwThreadId, DBG_CONTINUE );
    }

When a process calls CreateProcess with DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS specified in dwCreationFlags, the Debugger value of Image File Execution Options is not checked (makes sense, right? That's what the "Debugger" value is for). Thus, WithDll.exe can launch LaunchU3.exe without having LaunchU3.exe launch another instance of WithDll.exe. Launcherrific.

The last option is to modify the contents of the small CDFS partition on the U3 drive. This would allow one to toss the Detours programs (WithDll.exe and dependencies, as well as the "payload" DLL - a modified "Simple.dll" in this case) right onto the USB drive. Modify AutoRun.inf to kick off WithDll.exe with the right parameters, and the solution is clean and self-contained. Perhaps I will experiment with this... When I get more time =8->

Code for the Detours payload DLL:

#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501 // for WTSGetActiveConsoleSessionId
#endif

#include <stdio.h>
#include <windows.h>
#include "detours.h"

static BOOL (WINAPI* TrueProcessIdToSessionId)
            ( DWORD dwProcessId, DWORD* pSessionId ) = ProcessIdToSessionId;

static const unsigned short c_usLogTimeBufLen = 40;
static const unsigned short c_usMsgBufLen = 980;
static const unsigned short c_usFullMsgBufLen =
                                c_usLogTimeBufLen + c_usMsgBufLen;
static const char* const c_pszModName = "U3Detours";

void DebugPrint( const char* const pszFormat, ... )
{
    char szNowTime[c_usLogTimeBufLen + 1] = {0};
    SYSTEMTIME st = {0};
    ::GetLocalTime( &st );
    _snprintf_s( szNowTime, c_usLogTimeBufLen, c_usLogTimeBufLen,
        "%04d-%02d-%02d %02d:%02d:%02d.%03d", st.wYear, st.wMonth,
        st.wDay, st.wHour, st.wMinute, st.wSecond, st.wMilliseconds );

    va_list args;
    va_start( args, pszFormat );
    char szMsg[c_usMsgBufLen + 1] = {0};
    _vsnprintf_s( szMsg, c_usMsgBufLen, c_usMsgBufLen, pszFormat, args );
    va_end( args );

    char szFullMsg[c_usFullMsgBufLen + 1] = {0};
    _snprintf_s( szFullMsg, c_usFullMsgBufLen, c_usFullMsgBufLen,
        "%s ==> %s(TID=%d): %s\n", szNowTime, c_pszModName,
        GetCurrentThreadId(), szMsg );

    OutputDebugString( szFullMsg );
}

BOOL WINAPI InterceptProcessIdToSessionId( DWORD dwProcessId,
                                           DWORD* pSessionId )
{
    BOOL bSuccess = TrueProcessIdToSessionId( dwProcessId,
                                              pSessionId );
    if( !bSuccess )
    {
        DebugPrint( "ProcessIdToSessionId for PID %d failed with %d",
            dwProcessId, GetLastError() );
    }
    else
    {
        DWORD dwActiveConsoleSessionId = WTSGetActiveConsoleSessionId();
        DebugPrint( "ProcessIdToSessionId for PID %d succeeded; "
            "SessionId %d intercepted and being set to %d",
            dwProcessId, *pSessionId, dwActiveConsoleSessionId );
        // This is all we're really looking to do...
        *pSessionId = dwActiveConsoleSessionId;
    }
    return bSuccess;
}

BOOL APIENTRY DllMain( HMODULE hMod,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                    )
{
    (void)hMod;
    (void)lpReserved;
    LONG lErr = 0;

    if( DLL_PROCESS_ATTACH == ul_reason_for_call )
    {
        DebugPrint( "Starting..." );

        DetourRestoreAfterWith();
        DetourTransactionBegin();
        DetourUpdateThread( GetCurrentThread() );
        DetourAttach( &(PVOID&)TrueProcessIdToSessionId,
                      InterceptProcessIdToSessionId );
        lErr = DetourTransactionCommit();
        if( NO_ERROR == lErr )
        {
            char szExe[MAX_PATH + 1] = {0};
            GetModuleFileName( NULL, szExe, MAX_PATH );
            DebugPrint( "Detoured ProcessIdToSessionId in PID %d(%s)",
                GetCurrentProcessId(), szExe );
        }
        else
        {
            DebugPrint( "Error detouring ProcessIdToSessionId: %d", lErr );
        }
    }
    else if( DLL_PROCESS_DETACH == ul_reason_for_call )
    {
        DetourTransactionBegin();
        DetourUpdateThread(GetCurrentThread());
        DetourDetach( &(PVOID&)TrueProcessIdToSessionId,
                      InterceptProcessIdToSessionId );
        lErr = DetourTransactionCommit();

        DebugPrint( "Removed ProcessIdToSessionId: %d", lErr );
    }

    return TRUE;
}

This post originally appeared on an external website

This post originally appeared on an external website

I had a bit of a chuckle this morning when I fired up SharpReader:

The feed for Eric Lawrence's InsideHTTP was bad because "the server committed an HTTP protocol violation".

This post originally appeared on an external website

Sysinternals' Process Explorer can detect binary images it suspects are packed, and highlights them. Packed executables are highlighted in the top pane, and packed DLLs in a selected process are highlighted in the lower pane's "DLL View".

Interestingly, debug builds of binaries that link with Detours cause Process Explorer to suspect that the binary is packed ("Image is probably packed"). Release builds are not, however.

I would be interested to know how Process Explorer determines that a binary is probably packed.

This post originally appeared on an external website

I just noticed that the fix for the hibernation problems that I was experiencing and had to contact Microsoft Product Support Services for is now available for download to those "customers running genuine Microsoft Windows".

The problem is detailed in Knowledge Base article 909095, The computer occasionally does not hibernate and you receive an "Insufficient System Resources Exist to Complete the API" error message in Windows XP with Service Pack 2, in Windows XP Tablet PC Edition 2005, or in Windows XP Media Center Edition 2005, and the fix is available here. One must validate Windows prior to downloading.

This post originally appeared on an external website

This post originally appeared on an external website

[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.

This post originally appeared on an external website

This post originally appeared on an external website

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...

This post originally appeared on an external website

This post originally appeared on an external website

Hehehehe... I ran across the following in the "Microsoft Hardware Newsletter - Hardware Platform News Edition for : September 7, 2006":

This newsletter is composed and formatted on PCs running the Microsoft Windows Vista operating system.

Looks like some variation of this has been in place since 2006-07-25:

This newsletter is composed and formatted on PCs running a Microsoft Windows Vista operating system and the 2007 Microsoft Office system.

Does this imply then that the newsletter email was not processed by servers running Exchange Server 2007 on Longhorn Server?

This post originally appeared on an external website

This post originally appeared on an external website

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

This post originally appeared on an external website

I had tried several things to resolve this problem with no success, but after reading that it could be caused by a slow computer timing out, I decided to shut down the anitvirus-related services (running McAfee) and other non-essential services.  After doing this, I ran the "custom" update feature on Microsoft Update.  It ran so long that I thought it was going to fail again, but lo and behold, it finally finished, and I am now happily installing the updates.

Re: 0X8DDDD0009 Error Message.  I recently encountered this very annoying problem after loading Windows 2000 Professional on an IBM Thinkpad 1300 with a Pentium III & the maximum192 mb RAM.  Not being a computer geek, I only attempted the simple corrective measures as suggested on the windows update page ... all without success.  Since after initially loading Windows 2000 Professional I was able to successfully download all of the required O/S updates, I decided to retrace my steps back to the last successful update.  Well it turns out that the problem only developed after I changed the screen resolution from 800x600 to 1024x768 and McAfee Antivirus with on-access scanning was loaded.  I had no idea that these would tie-up some much of the system resources (available memory), until I checked the Task Manager.  In any event, temporarily changing the screen resoultion back to 800x600 and temporarily disabling the McAfee on-access virus scan, permitted the success downloading of new microsoft updates. It appears that the 0X8DDD0009 Error Problem in slower computers relates to low system resources and time-out limitations.  I trust that some readers will find this simple solution to a rather complex problem, helpful.

It seems that this might be a MS issue, especially after the release of their MS06-040 security patch. Aparently they are "shaping" the downloads so the important ones get delivered first.

Since it takes such a long time to download or even just to establish which updates to download, I took a different approach. After installing W2K, SP4 and IE SP1, installed as much other windows components as possible to eliminate downloading them as updates. These, amongst others, included MP9, DirectX 9C, .NET Framework 1.1. Also opened these and tried to run updates from within the apllications where posible. I futher noticed after struggeling for several days now that WU sometimes try to install newer updates before older ones. (For instance it tried to install a MP9 update while the original Media Player was still installed) I therefor used the "Custom" option and selected which updates to install first.

Although a very lengthy process, all worked out in the end. Good luck to all!!

This post originally appeared on an external website

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.

This post originally appeared on an external website

This post originally appeared on an external website

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

This post originally appeared on an external website

Heh.  Wonder what'll happen here. Sigh.  Taking features away is generally not a good idea.

-«/\/\Ø|ö±ò\/»®©

Tue 10/3/2006 1:10 PM
TechRepublic Blogger:

As many of you know, we are preparing to launch a new version TechRepublic. This revamp brings a fresh new look-and-feel to the site as well as improvements to features and functionality.

https://www.techrepublic.com.com/html/tr/preview/updated_TechRepublic.html

The process of revamping the site forced us to make some tough decisions about which features we would support going forward. Unfortunately, our member blogging feature didn't make the cut. So, with the launch of the revamp, we will be changing our approach to blogging on TechRepublic. Instead of giving every member the option to blog individually, we will be building a dozen or so topical blogs that have multiple contributors.

Starting next week, member blogs will no longer be available on TechRepublic. THIS MEANS THAT YOUR BLOG POSTS WILL NO LONGER APPEAR ON THE SITE AFTER THE LAUNCH. We apologize for any inconvenience that this causes; however, we feel that our new approach to blogging will better serve all of the members of TechRepublic.

Please feel free to contact me with any questions or concerns you may have.

Sincerely,

---------------------------------------------------------------------------------------
Shawn Morton
Site Manager - TechRepublic, CNET Networks