WMI Provider Extensions in .NET 3.5 – Publishing Events and Advanced Topics

April 30, 2008

The previous posts in this series described various mechanisms of communication from the WMI consumer to the WMI provider – including read-only properties, read-write properties and methods. However, publishing events from a WMI provider is the only scalable option of providing changing contextual information as it occurs. Pulling the information on demand is not an option because it doesn’t scale. In this post, we will use the BaseEvent class or the attribute to publish events from a WMI provider. Publishing events from a WMI provider is not supported by the WMI Provider Extensions for .NET 3.5....

WMI Provider Extensions in .NET 3.5 – Read-Write and Method Provider

In the previous post in this series, we have looked into implementing a rudimentary WMI provider which exposes read-only information.  In this post, we will make our provider more interesting by exposing read-write information. Read-write information is exposed by defining a read-write property and decorating it with the attribute. The , and requirements described in the previous post must still hold. The following code demonstrates a WMI provider which exposes a read-write property controlling the brightness of the screen. For demonstration purposes, the code to modify screen brightness has been omitted from the sample....
no comments

WMI Provider Extensions in .NET 3.5 – Introduction and Read-Only Provider

Windows Management Instrumentation (WMI) is a C&C infrastructure that is integrated within Windows. It provides three primary capabilities: Exposing state information regarding a configurable entity Invoking control methods on a configurable entity Publishing events from a configurable entity These facilities are a complete instrumentation solution for any Windows application, and multiple system components expose information through the use of WMI providers. This information can be consumed from a multitude of languages and technologies by WMI consumers, using a standard query language (WQL). Managed...
no comments

Don’t Blindly Count on a Finalizer

April 26, 2008

Finalization is one of the most complicated and obscure areas of .NET.  Most developers don't actually bother writing finalizers, but if you're designing and implementing any framework of considerable size, you are probably going to stumble across a well-defined set of issues.  And yes, it's not that simple to get it right - performance issues, concurrency issues, throttling issues, GC issues - there is a plethora of rocks to wreck your boat on. There are many resources out there that assist in getting finalization right, so I won't be repeating what others have written.  However, I would like to...

Parallelism and CPU Affinity

April 20, 2008

Contrary to popular belief, Windows actually does a good job scheduling threads for execution across the available CPUs.  (Yes, this was a controversial first sentence, but bear with me.) More often than not, smart developers tend to try to "outsmart" the operating system or framework that they happen to be using.  In the particular case of thread scheduling, this "outsmarting" normally tends to fall in one of two categories: Not trusting the OS with thread CPU affinity.  I.e., if I know that I have 4 cores, I will explicitly create 4 threads and assign each thread to its...

Design for Performance Up-Front?

April 12, 2008

There has been a lively discussion on Oren's blog with regard to whether it's appropriate to design for performance up-front when building an application.  I don't want to rephrase what Oren is saying (he makes an excellent case in these two posts), but it essentially boils down to the following three statements: You can always refactor for performance later. If an operation takes around the magnitude of a microsecond, then it is insignificant. Hotspots where abstractions must be removed are rare. As always, the correctness of the above statements highly depends on the environment you're in and the...

Automatically Converting Exceptions to WCF Faults

One of the annoyances in service design is that you have to dedicate lots of thinking to your error propagation strategy.  Any application framework or even utility class should be well-defined with regard to exceptions flowing to the outside world; however, when services are concerned, this is a matter of utmost importance. The reason for the distinction is the following simple notion: If you're dealing with an object, as the object's client you are very strongly coupled to its exception model.  You are well-aware of the fact that exceptions can propagate from the object and you have the facilities...

Next Generation Production Debugging: Demo 6

April 10, 2008

This is the last in a series of posts summarizing my TechEd 2008 presentation titled "Next Generation Production Debugging".  Previous posts in the series: Introduction and first demo (or how to survive without a debugger) Taking dump files and opening them up; analyzing a memory leak Dissecting deadlocks (native and managed) Analyzing an invalid handle situation After spending some quality time with the debugger, analyzing an invalid handle situation, I approached the final demo.  In this particular case, the application is requested to perform some heavy processing operation on a set of images (I called...

Next Generation Production Debugging: Demo 5

April 9, 2008

After looking at managed and native deadlock diagnosis, we transitioned to a state of banging our heads against the table, which is a state familiar to many developers from their debugging all-nighters.  How did we get in such a state?  By issuing the modest "Batch Move" command on a set of pictures we wanted to move to a separate folder.  The application responds in a way we have already seen before - it gets completely stuck. If you try deadlock diagnosis using the techniques I've shown earlier (WCT or the SOSEX !dlk extension), you won't find anything useful.  Our...
no comments

Next Generation Production Debugging: Demo 4

April 8, 2008

After utilizing WinDbg and SOS to diagnose a memory leak in our application, I shifted focus to a whole different category of problems - deadlocks. By issuing the "Move" command on a particular picture in the client application, the user ends up with a non-responsive UI.  We can't tell for sure whether the reason for the hang is in the UI or in the WCF service being called without forcing our way in with a debugger. However, there's a basic way of diagnosing deadlocks on Windows Vista and Windows Server 2008, which is built in into the operating system...