Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.
I guess I've got nothing to complain about. I'll let the screenshot speak for itself...
Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.
Previously, I wrote about the FLAGS switch for REG.EXE in Vista and covered a technique that would set the virtualization-related flags of a registry key programmatically. This post intends to cover the other side - querying for the virtualization-related flags of a registry key. Again, we're dealing with an "undocumented" function in NTDLL.DLL - NtQueryKey:
NTSTATUS NtQueryKey(
IN HANDLE KeyHandle,
IN KEY_INFORMATION_CLASS KeyInformationClass,
OUT PVOID KeyInformation,
IN ULONG Length
OUT PULONG ResultLength );
typedef enum _KEY_INFORMATION_CLASS {
KeyBasicInformation,
KeyNodeInformation,
KeyFullInformation,
KeyNameInformation,
KeyCachedInformation,
KeyFlagsInformation,
KeyVirtualizationInformation,
MaxKeyInfoClass // MaxKeyInfoClass should always be the last enum
} KEY_INFORMATION_CLASStypedef struct _KEY_FLAGS_INFO {
ULONG unknown1;
ULONG unknown2;
ULONG ControlFlags;
} KEY_FLAGS_INFO, *PKEY_FLAGS_INFO;typedef NTSYSAPI NTSTATUS (NTAPI* FuncNtQueryKey)( HANDLE KeyHandle, KEY_INFORMATION_CLASS KeyInformationClass, PVOID KeyInformation, ULONG Length, PULONG ResultLength );
// ...
FuncNtQueryKey ntqk = (FuncNtQueryKey)GetProcAddress( GetModuleHandle( _T("ntdll.dll") ), "NtQueryKey" );
KEY_FLAGS_INFO kfi = {0};
HKEY hTheKey = NULL;
RegOpenKeyEx( HKEY_LOCAL_MACHINE, _T("SOFTWARE\\Whatever"), 0, KEY_ALL_ACCESS, &hTheKey );
DWORD dwResultLen = 0;
DWORD dwNtqkResult = ntqk( hTheKey , KeyFlagsInformation, &kfi, sizeof( KEY_FLAGS_INFO ), &dwResultLen );
RegCloseKey( hTheKey );
hTheKey = NULL;
typedef enum _CONTROL_FLAGS {
RegKeyClearFlags = 0,
RegKeyDontVirtualize = 2,
RegKeyDontSilentFail = 4,
RegKeyRecurseFlag = 8
} CONTROL_FLAGS;
Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.
A while back, there was a topic (Virtual Registry vs. "Real registry") in the Sysinternals Forums that brought up the question of how to set the virtualization-related flags of a registry key programmatically in Vista, rather than through the use of the REG.EXE tool's FLAGS switch. (For more information on the flags, see Mark Russinovich's article in TechNet Magazine, "Inside Windows Vista User Account Control"). Even before that topic in the forum, I had wondered how it was done but had not had a chance to explore. It didn't seem that many others were curious about it. That topic had resurrected the idea, but it quickly fell to the bottom of the list. I've finally gotten around to experimenting, and that leads to this write-up. I still don't see much in the way of this discussed anywhere, by searching for terms involved (data types, function param names, etc.), so hopefully this will help someone. (Keep in mind that there very well may be a reason Microsoft hasn't made this available through another, more direct API.)
In the referenced topic, I had gotten so far as determining that REG.EXE was doing its work through the use of NtSetInformationKey, an "undocumented" API in NTDLL.DLL.
NTSYSAPI
NTSTATUS
NTAPI
NtSetInformationKey(
IN HANDLE KeyHandle,
IN KEY_SET_INFORMATION_CLASS InformationClass,
IN PVOID KeyInformationData,
IN ULONG DataLength );
After a bit of plonking around in WinDbg, I've come up with the following following details. REG.EXE calls NtSetInformationKey, specifying a value of 2 for the InformationClass parameter. This parameter is of type KEY_SET_INFORMATION_CLASS, which wdm.h tells us is an enum:
typedef enum _KEY_SET_INFORMATION_CLASS {
KeyWriteTimeInformation,
KeyWow64FlagsInformation,
KeyControlFlagsInformation,
KeySetVirtualizationInformation,
KeySetDebugInformation,
MaxKeySetInfoClass // MaxKeySetInfoClass should always be the last enum
} KEY_SET_INFORMATION_CLASS;So the 2 for the InformationClass parameter would correspond to KeyControlFlagsInformation. WDM.H also suggests that this class has a type that one passes for the KeyInformationData parameter - KEY_CONTROL_FLAGS_INFORMATION:
typedef struct _KEY_CONTROL_FLAGS_INFORMATION {
ULONG ControlFlags;
} KEY_CONTROL_FLAGS_INFORMATION, *PKEY_CONTROL_FLAGS_INFORMATION;We have a basic idea of how to call NtSetInformationKey now. But what are the values that the ControlFlags member of KEY_CONTROL_FLAGS_INFORMATION can be set to? It would appear that the following (self-made) enum covers the pertinent flags - at least the ones REG.EXE FLAGS can handle (there may be more):
typedef enum _CONTROL_FLAGS {
RegKeyClearFlags = 0,
RegKeyDontVirtualize = 2,
RegKeyDontSilentFail = 4,
RegKeyRecurseFlag = 8
} CONTROL_FLAGS;The control flags are a bitmask, so you can OR them to set more than one.
Now that we have this information, what's left? We need to put it all together in a call to NtSetInformationKey. So, we need to get a pointer to the function in NTDLL.DLL. Then, we can declare a struct of type KEY_CONTROL_FLAGS_INFORMATION, set the ControlFlags member to be what we wish, and open a key to the desired location in the registry, that can be passed to NtSetInformationKey. In the end, we wind up with something like the following (error handling has been omitted):
typedef NTSYSAPI NTSTATUS (NTAPI* FuncNtSetInformationKey) (
HANDLE KeyHandle,
KEY_SET_INFORMATION_CLASS InformationClass,
PVOID KeyInformationData,
ULONG DataLength );
//...
FuncNtSetInformationKey ntsik = (FuncNtSetInformationKey)GetProcAddress(
GetModuleHandle( _T("ntdll.dll") ), "NtSetInformationKey" );
KEY_CONTROL_FLAGS_INFORMATION kcfi = {0};
kcfi.ControlFlags = RegKeyDontVirtualize | RegKeyRecurseFlag;
HKEY hTheKey = NULL;
RegOpenKeyEx( HKEY_LOCAL_MACHINE, _T("SOFTWARE\\Whatever"), 0, KEY_ALL_ACCESS, &hTheKey );
ntsik( hTheKey, KeyControlFlagsInformation, &kcfi, sizeof( KEY_CONTROL_FLAGS_INFORMATION ) );
RegCloseKey( hTheKey );
hTheKey = NULL;
The code above is the equivalent of invoking REG.EXE FLAGS HKLM\Software\Whatever SET DONT_VIRTUALIZE RECURSE_FLAGS. To clear the flags, just set kcfi.ControlFlags to RegKeyClearFlags (same as REG.EXE FLAGS HKLM\Software\Whatever SET).
Hopefully, this will prove useful to those that have wished to set these flags programmatically. In a future post, I hope to explore querying for these flags, ala REG.EXE FLAGS HKLM\Software\Whatever QUERY.
Note that this exploration was done on Windows Vista SP1. I would expect the content here to also apply to Windows Vista (no SP) as well as Windows Server 2008, but...
Ahhhh, alliteration. Anyway, just noticed that one of the other sites has posted the cheesy comment I referenced in my previous entry, Set the Priority of a Process By Name Automatically, in Vista - Part 2. So, both saw fit to post the comments (took a while for the one site, though) - the first stamped 2008-01-31 2:37 GMT, and the second stamped 2008-01-30 13:40 GMT. No sign of Part 2 on either of these sites, though... Hmmm...
This isn't what I want to be writing about. But a recent discovery compels me to do so. So, I've decided to make this an experiment, and beg your apologies that this will not have much technical merit despite the title.
After the last post, Set the Priority of a Process By Name Automatically, in Vista (which probably could have been named a lot better), I discovered that the post had made its way to some other sites. These sites appear to pull content from all over the web, package it up as their own, and toss ads all over it. One is lucky if the site even references the original author or links back to the original location of the post. It's frustrating, to say the least. I'm all for distribution of knowledge and the like, but that's taking it too far. Maybe I shouldn't feel this way, but I (like others) put brain sweat and time into the work I do, and it would be nice if the source of the information would at least be cited if they're going to republish it without the author's consent.
So I visited two of these sites (which I have not yet decided if I will mention or not, for what I hope are obvious reasons) and attempted to leave comments. Of course the comments are moderated - don't want any upset victims coming in and raising he. The comments were along the line of:
As the author of the original article referenced here, I kindly request that those interested in it please read it at MY blog, <a href="http://mygreenpaste.blogspot.com">My Green Paste, Inc.</a>
My site does not currently have ads, and I am NOT even considering ads at this time.
–«/\/\Øö±ò\/»®© (molotov)
Can you guess what happened? Yep - the comments were not approved, and were never published on the sites in question. I then attempted to leave another comment at each copy of my posting. This time, one site saw fit to allow the comment, and the other one did not. I suspected NO comments would have been allowed through either site, so I was a bit surprised. The comment was a bit ridiculous given the content of the posting, and rather generic; perhaps that's why it was allowed. The comment was simply:
does this work for other os like XP or server 2003?
Amazing. It was posted at 2008-01-31 2:37 GMT. The comment, like this post, is a part of the experiment. See, if I mention things that I mentioned in the previous post, like CpuPriorityClass, image file execution options, IoPriority, PagePriority, PerfOptions, powershell, priority, Process Monitor, setpriorityclass, Sysinternals, Vista, WorkingSetLimitInKB, Vista, Windows Vista, Windows Vista Ultimate, etc. (sorry to get carried away there), will this post make it to these sites as well? If so, wouldn't that be somewhat funny? The comment falls in there, too - if the now published comment magically disappears from the copy of my previous post, won't that be a bit odd?
I think I'll have to start embedding a "this content originally from http://mygreenpaste.blogspot.com/" statement into the middle of each of my posts from now on. I'm sure I'll forget, and I've probably only got one shot. That'll make for some nice, flowing reading. We'll see.
I do have some more thoughts about the Set the Priority of a Process By Name Automatically, in Vista topic that I expect to get out in my next post. I apologize for this distraction, and hope you'll stay tuned...
BTW - I may also have a follow up to this fork in the saga as well.
The other day I was playing around with the Image File Execution Options and Sysinternals' Process Monitor, in Vista. I saw an interesting query take place. Using notepad.exe as an example, I saw a query for a key called "PerfOptions" in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe] when I ran notepad. The result was NAME NOT FOUND, so I decided to rectify that. After adding a key named "PerfOptions", I ran notepad again. In Process Monitor, I saw queries for four values:
Because of recent explorations with process priorities*, CpuPriorityClass grabbed me right away. Looking at the SetPriorityClass function, one can see the different values for the dwPriorityClass parameter. I created a REG_DWORD named CpuPriorityClass in PerfOptions, and set the value to 0x80 in the hopes that notepad would launch with "HIGH_PRIORITY_CLASS". Instead, it launched with a priority of NORMAL_PRIORITY_CLASS (8) - the setting had not made any impact. Then, I set the value to 8 and launched notepad. Notepad launched with a priority of 8. I changed the value to 4, and that had no impact. I changed the value to 0 - no impact. I tried 10 - no impact. I couldn't see any tie in to any other listings of process priorities that I knew about, so I decided to try trial and error, starting from 0, with the following results:
| CpuPriorityClass Value | Priority of Notepad | Priority Class |
| 1 | 4 | Idle |
| 3 | 13 | High |
| 5 | 6 | BelowNormal |
| 6 | 10 | AboveNormal |
| Anything else^ | 8 | Normal |
^= I'm currently running a PowerShell script to iterate through all possible values (there's only about 2^32...) so it may be a while before the CpuPriorityClass value for REALTIME_PRIORITY_CLASS, should it exist, be uncovered. There may also be other values that can be used to specify a priority class that's been uncovered. I'll update or post a new topic if I uncover anything new...
The PowerShell script (don't laugh, it's my first substantial attempt at one):
$cpc=0
set-itemproperty "hklm:\software\microsoft\windows nt\currentversion\image file execution options\notepad.exe\perfoptions" cpupriorityclass $cpc
do
{
$pp = [diagnostics.process]::start("notepad.exe", "")
$ppc = $pp.PriorityClass
$pp.Kill()
if( $ppc -ne "Normal" )
{
Write-Host $cpc $ppc
}
$cpc++
set-itemproperty "hklm:\software\microsoft\windows nt\currentversion\image file execution options\notepad.exe\perfoptions" cpupriorityclass $cpc
}
while( $cpc -lt 4294967295 )
Hopefully, I'll find time to do some digging into the other values in PerfOptions - IoPriority, PagePriority, and WorkingSetLimitInKB. IoPriority and PagePriority sound like they may have something to do with memory prioritization and IO prioritization in Vista. WorkingSetLimitInKB sounds self-explanatory, but how it's applied or how it's used, and other circumstances, are quite vague.
*= SetThreadPriority, Vista, and Autostart Locations, Setting the Priority of a Service Process via Script
After the previous BSOD in Vista, I logged in to Vista interactively as an administrator (I usually run as a standard user), and I was greeted with a dialog informing me about a "serious error" or the like. I chose to check for updates to the problem. What came back was more than I expected, but not really all that helpful for my particular situation.
I am running the latest driver, and ATI has discontinued the Radeon 9600 Pro. Not a big deal, as the problem has only happened twice. Of course, I would rather that it not happen at all...Problem caused by ATI Graphics Driver
This problem was caused by ATI Graphics Driver.
This program was created by ATI Technologies, Inc.. ATI Technologies, Inc. does not currently have a solution for the problem that you reported.
Recommendation
--------------------------------------------------------------------------------
The following troubleshooting steps might prevent the problem from recurring.
Download and install an updated version of ATI Graphics Driver from one of the following locations:
Microsoft Update
ATI Technologies, Inc.If an updated driver is not available for ATI Graphics Driver, check with your computer manufacturer.
If you are running the latest version of ATI Graphics Driver, contact ATI Technologies, Inc. for your support options.
Additional information
If this problem continues to occur after installing the latest product updates, we recommend you get assistance and troubleshooting information directly from ATI Technologies, Inc..
--------------------------------------------------------------------------------
»
Recently, after resuming my Vista laptop from hibernation, I was greeted with a rather strange wait, followed by a blue screen of death. Analysis of the dump yielded the following:
THREAD_STUCK_IN_DEVICE_DRIVER (ea)
The device driver is spinning in an infinite loop, most likely waiting for hardware to become idle. This usually indicates problem with the hardware itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it, and hit go to return to the spinning code to debug it further. Because KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines (OS builds <= 3790) it is possible to hit a timeout when the spinning thread is interrupted by hardware interrupt and ISR or DPC routine is running at the time of the bugcheck (this is because the timeout's work item can be delivered and handled on the second CPU and the same time). If this is the case you will have to look deeper at the offending thread's stack (e.g. using dds) to determine spinning code which caused the timeout to occur.
Arguments:
Arg1: 870246b8, Pointer to a stuck thread object. Do .thread then kb on it to find the hung location.
Arg2: 00000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 00000000, Pointer to offending driver name.
Arg4: 00000000, Number of times this error occurred. If a debugger is attached, this error is not always fatal -- see DESCRIPTION below. On the blue screen, this will always equal 1.Debugging Details:
------------------PEB is paged out (Peb.Ldr = 7ffd800c). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffd800c). Type ".hh dbgerr001" for details
FAULTING_THREAD: 870246b8
DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT
BUGCHECK_STR: 0xEA
PROCESS_NAME: Ati2evxx.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 89c2a825 to 81cace97
STACK_TEXT:
a53d7704 89c2a825 000000ea 870246b8 00000000 nt!KeBugCheckEx+0x1e
a53d7748 89c22bfa a53d7794 00000000 89c1d786 dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x2b
a53d7770 8b5785dc a53d7794 00000000 00000000 dxgkrnl!TdrTimedOperationDelay+0xc9
WARNING: Stack unwind information not available. Following frames may be wrong.
a53d77c0 8b576468 8b670040 a53d785c ffffffff atikmdag+0x255dc
a53d77dc 8b66782c 861bd000 a53d77f8 00000014 atikmdag+0x23468
a53d7838 8b670101 86a58008 8b670040 a53d785c atikmdag+0x11482c
a53d7868 8b6cd9da 8685b0e8 00000000 00000001 atikmdag+0x11d101
a53d7888 8b59f159 88340000 00000000 00000001 atikmdag+0x17a9da
a53d78a8 8b59505c 86a58000 86a61974 00000000 atikmdag+0x4c159
a53d78dc 8b5973e3 00000000 86a611e0 00000001 atikmdag+0x4205c
a53d7904 8b5b3be0 00000001 00000001 00000001 atikmdag+0x443e3
a53d7960 8b5b80ab 86a58000 00000000 00000001 atikmdag+0x60be0
a53d7980 8b58e38d 86a58000 a53d799c a53d7ba0 atikmdag+0x650ab
a53d79b8 8b554e80 86a58000 a53d7ba0 00000030 atikmdag+0x3b38d
a53d79dc 8b55a7de a53d7ba0 00000030 a53d7bd4 atikmdag+0x1e80
a53d7a00 8b55af33 0011000e 00000030 a53d7bd4 atikmdag+0x77de
a53d7a24 8b56bdeb 00000030 a53d7ba0 00000000 atikmdag+0x7f33
a53d7a54 8b56bf8a 00000000 a53d7b1c a53d7ba0 atikmdag+0x18deb
a53d7a74 89c4a7b2 8640a648 a53d7ab4 000000b8 atikmdag+0x18f8a
a53d7a94 89c4a455 a53d7ab4 a5b4b811 0012e910 dxgkrnl!DXGADAPTER::DdiEscape+0x3b
a53d7d38 81c4607a 0012e910 0012e94c 77940f34 dxgkrnl!DxgkEscape+0x4af
a53d7d38 77940f34 0012e910 0012e94c 77940f34 nt!KiFastCallEntry+0x12a
0012e94c 00000000 00000000 00000000 00000000 0x77940f34STACK_COMMAND: .thread 0xffffffff870246b8 ; kb
FOLLOWUP_IP:
dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2b
89c2a825 cc int 3SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2b
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 46899fd6
FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys
BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys
Followup: MachineOwner
Seems that the hardware was messed up, as I had to force the laptop to power down twice during subsequent boots, in order for Vista to make it to the logon prompt.
»
I ran across a post on the Vista Compatibility Team Blog entitled "SetThreadPriority from Run key" that discusses a change in Vista whereby calling SetThreadPriority from an application launched from the Startup folder and the "Run" key in the registry will not cause the thread's priority to be increased.
Wanting to verify and play around with this, I wrote a simple program that called SetThreadPriority to set the priority of the thread to THREAD_PRIORITY_HIGHEST. The program then immediately called GetThreadPriority to determine if the call to SetThreadPriority had any effect. Next, in a loop, the program then called SetThreadPriority / GetThreadPriority until either an error was encountered, or GetThreadPriority returned the expected priority. The program logged before and after each call to SetThreadPriority / GetThreadPriority the time, the action, and the either the parameters or the return value.
I set the program to be launched automatically by placing a shortcut in the "Startup" folder, and rebooted. Once the system came back up, I waited a bit and then examined the log. The first call to SetThreadPriority( GetCurrentThread(), THREAD_PRIORITY_HIGHEST ); returned TRUE. The first call to GetThreadPriority( GetCurrentThread() ); returned 0 indicating THREAD_PRIORITY_NORMAL. In other words, the call to SetThreadPriority had succeeded, but the priority of the thread remained unchanged. The calls to SetThreadPriority and GetThreadPriority in the loop were identical, and returned identical values. That is, until about 45 seconds into the program's execution, when the call to GetThreadPriority returned 2, indicating that the priority of the thread was THREAD_PRIORITY_HIGHEST. This matches what is mentioned in the "SetThreadPriority from Run key" blog entry, where it is stated that:
it is for about a minute or so after which the call to SetThreadPriority(THREAD_PRIORITY_HIGHEST ) will actually succeed in bumping up its priority level.
I repeated the same tests, using THREAD_PRIORITY_ABOVE_NORMAL in the call to SetThreadPriority, with the same results.
I also used THREAD_PRIORITY_BELOW_NORMAL in the call to SetThreadPriority as well as THREAD_PRIORITY_LOWEST; in these cases, the call indicated success and GetThreadPriority confirmed the change in priority immediately.
The next set of tests removed the call to SetThreadPriority in the loop - just the initial call to SetThreadPriority was made. The return indicated success, but the call to GetThreadPriority returned THREAD_PRIORITY_NORMAL for many minutes; as the loop was a tight loop, I terminated the process once it became apparent that there truly would be no change to the priority of the thread. This means that requests to increase the priority are not queued up or held for later processing. The call to increase priority indicates success, the priority is not changed, and unless the thread checks, it is none the wiser.
One other thing that I thought of trying was to see what happened when a thread in a process spawned by an "autostart" process called SetThreadPriority, as above. To do so, I modified the original program to accept a command-line parameter indicating that it should spawn another instance of itself. The thread in the spawned process behaved identically to the thread in the "autostart" process; this persisted 3 "levels" deep ("autostart" instance spawns instance x, which spawns instance y), which is as deep as I tried. The Vista Compatibility Team Blog entry only mentions the Startup folder and the "Run" key as being affected by this, but I wonder if other things may be affected. It is interesting (and a good thing!) that there is a mechanism in place to cause this behavior to affect processes spawned by autostart processes (otherwise, the "protection" offered by this feature is easily defeated).
As a last test, I invoked the test program manually as quickly as I could while Vista was still processing the login. The first attempt to change the priority of the thread succeeded, and the first call to GetThreadPriority confirmed the priority change. At the same time, Vista was processing the autostart instance of the program, which behaved as it had previously when started automatically. So there is not a blanket ban on priority boosting in the first minute or so - how a program is started truly affects what it can do.
»
I use ReadyBoost in Vista. One day, I went to power up my laptop and when Vista resumed from hibernation I noticed that the light on the USB Flash-memory Device (UFD) was not on. Finding this a bit odd, I jumped into Windows Explorer, double-clicked on the E drive (the letter assigned to the UFD), and was presented with an interesting dialog:
Title: Item Not Found
Text: Could not find this item
This is no longer located in <%3 NULL:OpText>.
Verify the item's location and try again.
Removable Disk
Try Again Cancel
So I looked at the back of my laptop to verify the item's location, and deciding that the item was still there I clicked "Try Again". (I know, I know - not really what the person who wrote the message for the dialog intended...) I don't recall if the dialog dismissed and another instance reappeared, or if it was just that nothing happened. Either way, I wasn't getting anywhere. I unplugged the UFD, and plugged it back in again and things were fine.
A few days later, the same thing happened. I suspect I'll be dealing with this for a while.
Procedurally, I hate to think that I'm going to have to eject the device prior to hibernating, and then plug the device in again when Vista resumes - that's too tedious for my tastes. ReadyBoost would have to have a significant impact on performance for me to go through that rigamarole, and at this point I'm just not convinced that's the case.
Anyone else coping with %3 NULL:OpText? How are you dealing with it?
»
A quick one this week...
Ran into an interesting posting at shell: revealed about features of Longhorn that didn't make the cut. The post paints the picture that after the Longhorn reset (described here), a lot of features were yanked, and then goes on to describe some rather humorous things that just make you think... "What if?"
»
...or choose type of feed:
Posts
All Comments
(Experimental - let me know how this works!)
