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.
I was recently working on getting Windows Media Services configured on a system. Going through the properties, I noticed that the "WMS Anonymous User Authentication" plugin was in an error state. On inspection, I was presented with the following dialog.
---------------------------
Windows Media Services
---------------------------
The plug-in cannot be enabled because the user name or password does not match the settings for the Windows user account used for anonymous guests.
---------------------------
OK
---------------------------
Also, the event viewer was showing the following:
Event Type: Error
Event Source: WMServer
Event Category: Plugin
Event ID: 323
Date: [Date]
Time: [Time]
User: N/A
Computer: [CompName]
Description:
Plug-in 'WMS Anonymous User Authentication' on the server failed with the following information: Error code = 0x8007052e, Error text = 'Logon failure: unknown user name or bad password. '.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 8007052e
Checking "Local Users and Groups", I could see that the specified user (WMUS_COMPNAME) certainly existed. I changed the password for the user and then set the password in the properties for "WMS Anonymous User Authentication". I was rewarded with the same message. The user name and password were correct, so I focused my attention elsewhere. I first tried changing the settings to provoke the message while running Sysinternals' Filemon and Regmon, but was unable to pull anything from the captured data that seemed like it was germane to the problem.
The next thing I tried was creating a new account and specifying that account in the properties for "WMS Anonymous User Authentication". This worked; the status of "WMS Anonymous User Authentication" became "Enabled". I found this odd, as I was working with a fresh installation of Windows Media Services. In comparing the accounts (WMUS_COMPNAME and the test account I created), I noticed the WMUS_COMPNAME account was just a member of the Guests group, while the test account was just a member of the Users group. So, I added the test account to Guests and removed it from Users, and then checked / OK'd the "WMS Anonymous User Authentication" properties. I got the aforementioned message. I changed the test account back to the original group memberships, and "WMS Anonymous User Authentication" did not complain.
At this point, I knew that the problem was related to some restriction placed on the Guests group. I ran secpol.msc to check the Local Security Policy Settings, and I noticed that Guests had been added to the Security Setting for the "Deny access to this computer from the network" policy. According to TechNet, the default for this policy is "None". Removing Guests from the setting allowed the WMUS_COMPNAME account to function as the anonymous account used by Windows Media Services.
A while ago, I noticed a handle leak in Apple's "Bonjour Service" (yeah, that sounds like something I want running on my system...) - mDNSResponder.exe. I knew right away that that was the executable for the "Bonjour Service" because the name is so helpful. (Joking. Even if it was named after the service, how the heck would I even guess what the "Bonjour Service" did. But I digress...)
The service description is:
Bonjour allows applications like iTunes and Safari to advertise and discover services on the local network. Having Bonjour running enables you to connect to hardware devices like Apple TV and software services like iTunes sharing and AirTunes. If you disable Bonjour, any network service that explicitly depends on it will fail to start.
I put up with the leak for a while, from time to time stopping the service when I thought of it after booting. Most of the time I didn't think of it and the leak did not appear to be having any kind of performance impact on my system (I never saw it get above 80,000 handles). An update (or two?) later, I thought it would be fixed. So I was surprised to find mDNSResponder.exe had more than 55,000 handles when I checked recently with Sysinternals' Process Explorer.
I tried to use Process Explorer's handle pane to see the handles in mDNSResponder.exe, but with that many handles to display, and with Process Explorer running with its default High priority and refreshing every second, the system became rather sluggish. I dropped the priority of Process Explorer with Task Manager, hid the lower-pane view, and gave Handle.exe a shot with handle.exe -a -p mdnsresponder.exe.
I found that the handles being leaked are handles to registry keys - specifically, HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters. (ControlSet001 is the current control set on my system.)
Since there's not much I can do about the handle leak, I'll disable the service, and hope the next update fixes the problem as surely the next update will set the service to Automatic start. Wonder why the installer doesn't at least set a service such as this as "Delayed Start" in Vista...
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.
Just a quick note - the authors of Advanced Windows Debugging have been interviewed on MSDN's Channel 9. It's about 43 minutes long, and it's interesting to hear the authors talk about their experiences, the motivation behind the book, the effect of additional layers of abstraction, etc., and go through a handle leak debugging session. Check it out!
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.
Was having a little fun with rundll32.exe (command-lines will probably be a little messed up due to the length - they should be entered as one complete command). I first tried the commands on XP, but they produce similar results on Vista.
C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\system32\sysdm.cpl,NoExecuteProcessException C:\windows\system32\ntoskrnl.exe
C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\system32\sysdm.cpl,NoExecuteProcessException C:\windows\system32\hal.dll
C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\system32\sysdm.cpl,NoExecuteProcessException C:\windows\system32\chkdsk.exe
C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\system32\sysdm.cpl,NoExecuteProcessException C:\windows\system32\autochk.exe
C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\system32\sysdm.cpl,NoExecuteProcessException C:\windows\system32\smss.exe
C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\system32\sysdm.cpl,NoExecuteProcessException C:\windows\system32\winlogon.exe
C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\system32\sysdm.cpl,NoExecuteProcessException c:\windows\Soap Bubbles.bmp
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.
Congratulations to AD for the public release of the beta of RootRepeal, a new rootkit detector!
See the tool's site on GooglePages for more info or to download:
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.
Ran into the following while configuring IIS 6 on a new system. Not sure if I need to be concerned...
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 recent topic in the Development forum at Sysinternals Forums contains some information about how to use Visual C++ 2008 to create binaries that run on Windows 9x and NT. For NT, it seems to just be a matter of changing the Subsystem Version to 4.0. One might think to use the /SUBSYSTEM linker switch for this. However, when one attempts to do so, the shipping link.exe reports:
LINK : warning LNK4010: invalid subsystem version number x.y; default subsystem version assumed
In this case, the default subsystem version is 5.0, and NT needs 4.0. One can use an older copy of EditBin.exe to change this (I found the version that shipped with Visual Studio .NET 2003 to work):
editbin /SUBSYSTEM:CONSOLE,4.0 c:\path\to\your.exe
The same requirement also exists to get the executable to run on Windows 9x, but one needs to do a bit more work.
Louis Solomon has taken the time and put forth the effort to find what is needed for this, and has documented it at C/C++ EXEs and DLLs created by Visual Studio 2008 don't run on Windows 4.0 (ie, NT4 and Win9x).
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...
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 had written about the puzzlers on the NTDebugging / Microsoft Advanced Windows Debugging and Troubleshooting blog - specifically, the most recent puzzler which involved reverse engineering some assembler. The answer was posted today - there were a lot of responses, and a lot of correct responses.
I had posted the hashes for my answer (which was correct), that I am now able to disclose...
void myfun( char* param1 )
{
size_t local1 = strlen( param1 );
for( int local2 = local1; local2 > 0; local2-- )
{
for( int local3 = 0; local3 < local2 - 1; local3++ )
{
if( *(param1+local3) > *(param1+local3+1) )
{
char local4 = *(param1+local3);
*(param1+local3) = *(param1+local3+1);
*(param1+local3+1) = local4;
}
}
}
}
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.
Over on the Microsoft Advanced Windows Debugging and Troubleshooting blog, they've been posting a "Puzzler" every Monday and providing the answers the following Friday.
The puzzlers are fun to participate in and it is interesting to read people's responses - everyone has their own ideas and own experiences to draw off of.
With the third puzzler, the blog authors have decided to make the challenge a bit more difficult - the latest puzzler requires one to reverse engineer some assembler.
I've not got much experience with reverse engineering assembler - I can read some assembler and can usually get a very basic idea of what a targeted chunk of code is doing. So it was an interesting challenge for me to attempt to C-ify the assembler they provided. It doesn't appear that the authors are posting the responses until they reveal the answer (makes sense to me!). But I thought I'd post hashes of my response, which I'll also post once the NT Debugging blog authors post the answer and submitted comments / responses.
From Sigcheck:
Z:\NTDebuggingPuzzler3>sigcheck -h TheFunc.txt
Sigcheck v1.52
Copyright (C) 2004-2008 Mark Russinovich
Sysinternals - www.sysinternals.comZ:\NTDebuggingPuzzler3\TheFunc.txt:
Verified: Unsigned
File date: 12:52 PM 4/22/2008
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: 755394f9711b80968f17c8ffcb8f2394
SHA1: e8443f09eef43f2575aa08ba25f68267dba7243e
SHA256: 0e044419ef78f2fa7a8e258098f4f658426a8dc3e8a5b9a121a352c2dbbbfafc
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.
OK, so perhaps chaos is a bit of a harsh word here. But the clipboard was recently driving me nuts! All I was trying to do was copy some text to it, and the operation was failing. Of course, as it was an ad hoc app, I didn't have any kind of error handling. The app worked just fine on one system, but running the app on another system (a virtual machine) consistently resulted in failure to copy the text to the clipboard.
Ultimately, I was able to determine what process was preventing my app from putting data in the clipboard, but I haven't yet found a decent workaround for when the problem happens. It's not critical for me, as the act of copying the text to the clipboard is more of a nicety than a requirement.
Anyway, using P/Invoke and System.Diagnostics, I found that vmusrvc.exe - the Virtual PC "Virtual Machine User Services" - had the clipboard open. Using the timestamps from Process Monitor's Profiling Events (generated at 100 ms intervals), and the timestamp of the failed operation from my app, I was able to determine the stack of vmusrvc.exe:
| ntdll.dll | KiFastSystemCallRet |
| vmusrvc.exe | vmusrvc.exe + 0x9a17 |
| vmusrvc.exe | vmusrvc.exe + 0x9c24 |
| vmusrvc.exe | vmusrvc.exe + 0x91f8 |
| vmusrvc.exe | vmusrvc.exe + 0x907f |
| USER32.dll | InternalCallWinProc + 0x28 |
| USER32.dll | UserCallWinProcCheckWow + 0x150 |
| USER32.dll | DispatchClientMessage + 0xa3 |
| USER32.dll | __fnDWORD + 0x24 |
| ntdll.dll | KiUserCallbackDispatcher + 0x13 |
| vmusrvc.exe | vmusrvc.exe + 0x2d29 |
| vmusrvc.exe | vmusrvc.exe + 0xdba6 |
| kernel32.dll | BaseProcessStart + 0x23 |
No parameters, of course, and symbol information for vmusrvc.exe does not appear to be available, but obviously user32.dll is processing some message. I may look into this more at a later point.
To find the process that was interfering with my clipboard work, I used P/Invoke to call GetOpenClipboardWindow() and then GetWindowThreadProcessId(), passing in the handle returned by GetOpenClipboardWindow(). Then, finding the process' executable name was just a matter of using the Modules collection of the Process instance returned by passing in the process id retrieved by GetWindowThreadProcessId() to System.Diagnostics.Process.GetProcessById().
The following code:
using System.Runtime.InteropServices;
using System.Diagnostics;
...
string data = "aasdlkjasdlk alkjsdl kajsdlkj al";
try
{
Clipboard.SetData( System.Windows.Forms.DataFormats.Text, data );
}
catch( ExternalException ee )
{
LogIt( ee.ToString() );
IntPtr hWnd = GetOpenClipboardWindow();
if( IntPtr.Zero != hWnd )
{
uint pid = 0;
uint tid = GetWindowThreadProcessId( hWnd, out pid );
LogIt( "Process with hWnd {0}, PID {1} ({1:x}), TID {2} ({2:x}), " +
"name {3} has the clipboard", hWnd, pid, tid,
Process.GetProcessById( (int)pid ).Modules[0].FileName );
}
}
Resulted in the following output:
2008-03-25 00:54:45.4938864--> System.Runtime.InteropServices.ExternalException: Requested Clipboard operation did not succeed.
at System.Windows.Forms.Clipboard.ThrowIfFailed(Int32 hr)
at System.Windows.Forms.Clipboard.SetDataObject(Object data, Boolean copy, Int32 retryTimes, Int32 retryDelay)
at System.Windows.Forms.Clipboard.SetData(String format, Object data)
at Clippy.Form1.button1_Click(Object sender, EventArgs e)
2008-03-25 00:54:45.5339440--> Process with hWnd 65716 (65716), PID 1492 (5d4), TID 1496 (5d8), name C:\Program Files\Virtual Machine Additions\vmusrvc.exe has the clipboard
Interestingly, trying an alternative method of the Clipboard to set the content also failed. The Clipboard.SetDataObject() overload that takes a retryTimes and retryDelay parameter failed in the same fashion after roughly ten seconds when invoked as follows:
Clipboard.SetDataObject( data, false, 100, 100 );
I tried variations on retryTimes and retryDelay, to no avail.
Not sure what vmusrvc.exe is doing with the clipboard (probably has to do with monitoring it for host / guest VM interaction), but the act of setting the contents of the clipboard didn't fail 100% of the time in the VM. Often enough to make it extremely unreliable, though. During "normal" system usage, I was not able to cause a failure when running the app on a non-virtual (actual?) system.
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.
Twice now in as many months I have been the proud recipient of a BSOD on XP. The crashes were identical to each other with only various addresses being different (modules loaded into a different location and the like). They appear to have been caused by a bug in w29n51.sys; the crashes are of the IRQL_NOT_LESS_OR_EQUAL (a) variety. w29n51.sys is the "Intel® Wireless LAN Driver". Admittedly, I'm running a version that is likely not the latest. But it is interesting that googling the relevant stack entries (w29n51+0x1291, w29n51+0xa6af) turns up no hits. Also of interest is that the driver file is larger than 3 MB - more than 3 times the size of the next largest driver file in %systemroot%\system32\drivers... Strings does show a large number of verbose log-type messages that one can presumably cause to be logged via some configuration setting, as well as "tabular" data.
Of course, it is also disturbing that at the time of these crashes, the wireless hardware was disabled on this laptop...
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.
Raymond Chen posted about a topic yesterday that seems to hit the nail on the head with regard to some of the recent posts I've made here. In What's with all those spam ping-bots?, he describes the methodology used by blog and comment spammers / content thieves, and the motivation ($$) for doing what they do.
Of interest:
(You may notice that many of these sites mis-attribute the authorship; some of them even claim to have written the article themselves!)
Raymond also offers some advice about what one can try to do to "hit them in the pocketbook".
Sadly (ironically?), as I write this, 50% of the comments to that very blog entry are of the type that Raymond was writing about.
So it appears that there is not much that one is going to do to curb this. Also, considering that much of the content here (not just the newer stuff) has already been picked up and assimilated into other sites that slap a label on it as their own, and have even translated it (?????) into foreign languages, and then stamped ads all over it, I'm not inclined to waste much effort on the matter. I'll simply preface each entry with what you have seen the last few articles start with, and hope that that part of it makes its way along with the article to wherever it winds up. I may intersperse one or two similar statements in the longer articles as well. I hope it's not too distracting...
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.
Recently, an individual going by the moniker 'hi' posted a comment to Setting the Priority of a Service Process via Script:
How would I, if I want to, find which services are part of a particular svchost.exe? Can in be done in C#?
Thanks!
I replied via comment, but one has even less control over formatting in comments than one does in the actual blog posting, so I figured I would post the response here as well.
=================
Tasklist.exe with the /svc param can tell you, as can Process Explorer. You can also inspect the registry to determine what services would load with what SVCHOST group (see "Troubleshooting Performance Issues with Automatic Updates" for more details).
As far as C# code, the following requires a reference to System.Management. Invoke the program, passing it the process id of the process you're curious about, and it will output the services running in that process.
using System;
using System.Management;
namespace MyGreenPaste
{
class Program
{
static void Main( string[] args )
{
if( args.GetLength( 0 ) <= 0 )
{
Console.WriteLine( "Usage: {0} pid",
System.IO.Path.GetFileName(
System.Diagnostics.Process.GetCurrentProcess().
MainModule.FileName ) );
Console.WriteLine( " where pid is the process id " +
"of a process hosting at least one service" );
return;
}
try
{
ManagementObjectSearcher mos =
new ManagementObjectSearcher( "root\\CIMV2",
string.Format( "SELECT * FROM Win32_Service " +
"where ProcessId={0}", args[0] ) );
foreach( ManagementObject result in mos.Get() )
{
Console.WriteLine( "{0} -> {1}", result["Name"],
result["DisplayName"] );
}
}
catch( ManagementException mex )
{
Console.WriteLine( "** Error querying WMI:{0}{1}",
System.Environment.NewLine, mex.Message );
}
}
}
}
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..
--------------------------------------------------------------------------------
»
Ran across this rather unique notion the other day. It works!
eb poi(@$peb+0x8)+0x36fa c6 00 8aMy interpretation is that this "enters byte values" "c6 00 8a" into the address starting at offset 0x36fa from the value pointed to by offset 8 into the PEB. Whatever that ultimately does! »
Another update to the IE6 and IE7 Virtual PC images that the IE Team at Microsoft makes available is available for download in the Microsoft Download Center. The previous ones expired on 2007-12-07; these expire on 2008-04-01.
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.
»
Previously, I had written about IE6 and IE7 Virtual PC images that the IE Team at Microsoft makes available. As the previous release of the VPCs has expired, a refresh release has been issued. The new release expires on 2007-12-07.
»
Microsoft has recently published an "Events and Errors Message Center" on TechNet. It is a bit like EventId.net, but you can search on more fields than Event ID and Source (note that non-Microsoft products aren't included in the Microsoft offering).
The basic search allows for selection of a Microsoft product, and a search string. The advanced search adds a Version field for the selected product, an Event ID field, an Event Source field, a File name, and Language. The product list isn't yet all that comprehensive with only 18 entries (and some duplicates or products that could be further filtered by version), but I hope to see it grow to encompass more products and more versions (Vista is not listed yet, for example). It would also be cool if the capability to annotate specific events was made available to users, much like can be done at EventId.net. Another idea that would be nice to see is that as products are developed / maintained / updated, part of the process would involve documenting the events and their meaning, in the same database that the Events and Errors Message Center interfaces with. Perhaps QA and other groups could even add their own annotations to specific events - what caused the problem, how the problem was resolved, etc.
Hopefully, the Events and Errors Message Center keeps improving. Along similar lines, it would be nice to see the DLL Help Database get some attention - several times I have hoped to see Vista files appear but have been disappointed.
»
If you need to run IE 6 and IE 7 on the same system for some reason (testing?), what are you supposed to do?
One solution is the "Multiple IE installer" from TredoSoft. I haven't tried it, but it is certainly a novel approach. Looks like you can run IE3, IE4.01, IE5, IE5.5, and IE6 with it.
TredoSoft also provides instructions and a utility that allows you to run IE7 side-by-side with IE6. Again, I haven't tried it, but it is good to know that it is available.
When I need to test different versions of the browser, I have as of late been relying on VPC images of Windows XP with IE6 and IE7 that have been provided by the IE team. The VPC images run with the free Virtual PC 2007. They expire on 2007-08-17, for various reasons, but the IE team has in the past provided a "refresh" for the IE6 VPC image when it last expired, and the expectation is that this will continue. The expiration-refresh cycle allows for control over how "old" an image is allowed to get - refreshes have the latest security patches installed so people aren't left running ancient and (overly) vulnerable VPC images.
The images won't pass WGA for obvious reasons but this hasn't affected my ability to test with them.
I tend to customize my IE settings pretty severely, so it is nice to be able to test with "stock" / "virgin" installs of IE. One might argue that using the VPC images doesn't necessarily mean one has two different versions of IE on the same system - that the introduction of a VM means another "system" is involved. While this is true, the VM solution does prevent one from needing to have multiple physical machines around just for the sake of testing. And, while the TredoSoft solution may work, I can't help but think that the possbility exists for the solution itself to be a potential cause of problems.
»
I recently received the following via email. I responded, but never heard back. Hopefully the information will be of use to others...
I responded with the following:Hi, Found your name on the web when I was looking at some stuff on slashdot and I thought maybe you might have a moment to point me in the right direction.
I have a custom app which I have zero access to in terms of the developer. When the app was run on new hardware, a few users would periodically get a bizarre error, but never on their old hardware. Main difference seems to be core 2 duo on the new laptops.
Anyway, this error causes a total reset of the internal windows database system used by the app and then there's an error in msvcr80.dll. Is there a way I can tell from the data below what routine went bad in that module? I could at least then tell the guy who guards the gates to tell the developer a little bit more. At this point the "guard" is convinced it is just because the dll is not the latest version. I think it is probably not that simple.[app].exe signature
Appname [app].exe App. Ver. 0.0.0.0
Mod Name: msvcr80.dll
Mod Ver: 8.0.50215.44
Offsett: 000161fd
Error report contents
Exception info:
Code 0x0000005
Flag 0x00000000
Record 0x000000000000000
Address: 0x000000007C3861fd
It does appear that the problem may lie in the version of MSVCR80.DLL you referenced. At least, getting this to an appropriate version seems like a very reasonable first step towards troubleshooting.
According to a dude on the VC++ compiler team (Jonathan Caves @ http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465&SiteID=1&PageID=1 ), version 8.0.50215.44 of MSVCR80.DLL "is not an officially released version"; he links to this site (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 ), which has a statement by another member of the VC++ team (Martyn Lovell):
"a) This is the beta 2 version of msvcr80.dll. Don\'t install it. b) This file should never be installed in system32 (except on Win9x and Windows 2000). c) The .NET framework already installs the copy correctly (in WinSxS). d) The correct source for an msvcr80 binary is from your application provider, not from this site. Martyn"
The MS DLLHelp Database entries for MSVCR80.DLL (http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=msvcr80.dll&S=1 ) indicate that you can get the DLL from "MS SQL 2005 Server Enterprise" or "Microsoft Visual Studio 2005 Professional". Martyn from Microsoft indicates that you should get this DLL from the application provider. He also stated that you can get it as part of the .NET Framework redistributable (version 2.0). It also appears that you can get it as a part of a package from the "Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)" at http://www.microsoft.com/downloads/details.aspx?FamilyID=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en.
FWIW, 0x0000005 is not a valid exception code, though I suspect you meant 0xc0000005, which is the code for an access violation. You're reporting a crash at address 0x7C3861fd. With no other info it is difficult to determine what is loaded at that address (especially since the "shipping" / non-beta versions of MSVCR80.DLL are based at 0x78130000 with a virtual size of 0x9b000), but it seems likely that the beta version of MSVCR80.dll has a different base address (0x7C370000) / size which could/should include the crash address (or, the DLL could have been rebased by the loader).
I suspect that a "Dr. Watson" or "Windows Error Reporting" dump file may have been created from the application crash(es) - these are files with a .dmp extension, and they contain information useful for debugging, or getting more information about, these kinds of problems.
Hope this helps you!
-molotov
I was reading a recent blog entry by Eric Sink, and he made some comments that I thought I would take the time to share. Nothing profound on my end, mind you... ;)
In "In defense of Petzold's WPF book", the founder of SourceGear writes about a recent trend in books and tools for developers that focus on "quick results", and the trade off that goes along with this trend - loss of "deep understanding". I too have noticed this in working with various developers. While it is admirable that one is able to produce results quickly and ship a product in record time, or add some features in the blink of an eye, it seems that much of the productivity is lost when problems crop up - problems that are at least partially a lack of - you guessed it - deep understanding. As I'm one who likes to have Deep Understanding, I'm probably biased. That said, I can fully appreciate Eric's statement that "When I hire a software developer, I look for deep understanding". I think that it is important to understand how something works so you are able to use it as effectively as possible. Perhaps this is why I am inclined to consider writing software an art, as opposed to a means to an end. Sure, it's both, but how you treat it can have a significant impact on the quality of the end product. At least, that's been my experience.
To me, Deep Understanding implies passion - if one takes the time to understand something fully, to explore all venues of a topic or a technology, they truly care about what it is they're doing and are excited by it. And I can't see doing something as a profession and not being passionate about it.
»
Just received the following that is related to the SVCHOST issues that I've written about in the past...
MS has released "Microsoft Security Advisory (927891) - Fix for Windows Installer (MSI)" that's not really a direct security concern, but actually addresses concerns that might prevent people from getting critical security or other updates.
As previously mentioned, it involves MS KB 927891 - "You receive an access violation error and the system may appear to become unresponsive when you try to install an update from Windows Update or from Microsoft Update", and the current revision of the article (8.0) states "This fix is one component of a two-part fix that includes a Windows Update client software update. These updates will be deployed automatically using Windows Update in May 2007 and June 2007."
Again, this update is one of two that need to be applied to fully address the issue. The other update is version 3.0 of the Windows Update Client Software, available from MS KB 932494, "When you use Automatic Updates to scan for updates or to apply updates to applications that use Windows Installer, you experience issues that involve the Svchost.exe process".
One can also hope that this will help address the 0x8ddd0009 problems that MANY have been experiencing...
»
...or choose type of feed:
Posts
All Comments
(Experimental - let me know how this works!)
