Displaying Performance Monitor Information through an ASP.NET Web PageBy Scott Mitchell
In two previous articles - Displaying Information about the ASP.NET Process and How Long has the Web Server Been Up? - I examined how to display system-level information through an ASP.NET Web page. In the first article, information about the ASP.NET process was displayed, while in the second page the time the Web server had been running without a reboot was provided. While both of these articles showed how to provide useful system-level information through a Web page, I hinted in those articles that one could display any system-level tidbit of information that was residing in the Windows Performance Counter.
The Windows Performance Counter contains a useful system-level information broken down into various categories. For example, in the Processor category you can view the % Processor Time, the % User Time, the number of Interrupts/sec, etc.; in the Memory category you can view the available amount of memory, the number of page writes/sec, etc. There is also an ASP.NET category and an ASP.NET Applications category. In the ASP.NET category you can view stats for the ASP.NET process, like the number of application restarts, the number of running applications, the request wait time, the number of requests queued, etc. In the ASP.NET Applications category you can view these stats for a particular Web application (virtual directory), as well as stats on output caching, transactions, errors, etc.
In this article we will examine how to display the performance counter variables through an ASP.NET Web page. Once we learn about how to work with the security measures put in place to prevent anonymous users from accessing the performance counter data, we will look at the (very simple) code needed to access the performance counter data.
Getting Access to the Performance Counter
If you try the code presented below before you read and apply the lesson in this section, you will get security errors (specifically a
System.ComponentModel.Win32Exception: Access is deniedexception). This is because the Performance Monitor is quite choosey on who, exactly, it will share its information with. Specifically, the Performance Monitor is only interested in sharing its data with system-level accounts, such as the Administrator account. By default, when a request comes through the ASP.NET engine, the request is made using an ASPNET user account (as specified in the
machine.configfile). This is a Good Thing - if some malicious hackers find a way to exploit an ASP.NET security hole, you don't want the hackers to be able to access your Web server using the Administrator account.
Of course you can specify that ASP.NET requests be treated as a system-level account. To accomplish
this (highly unadvised) task, open up
machine.config (likely found in
$WINNT$\Microsoft.NET\Framework\v1.0.3705\CONFIG) and find the
setting. In it, change the
UserName attribute from
SYSTEM. Once this change is made, you will be able to view the performance monitor data.
Let me reiterate that by setting the
UserName property to
SYSTEM you are
opening up yourself to a world of hurt should some sort of exploit be found in ASP.NET that allows anonymous
Web users to execute commands on the Web server. A much (much much much) better approach, and probably
what you're after anyhow, is to only allow a certain subset of users access to the performance monitor
data. For example, you may only wish to allow folks who have actual Windows username accounts on the
Web server (or Web server domain) and who have administrative (system-level) rights.
To accomplish this, what you will want to do is create a virtual directory on your Web server (a new
ASP.NET Web Application, for those of you using Visual Studio .NET) and provide the following information
Web.config file (within the
(Note that the
<identity impersonate="true" /> must appear in a Web application's
These settings essentially do the following:
<authentication mode="Windows" />- This informs ASP.NET to authenticate users using Windows security. That is, when a user comes into the site ASP.NET defers to IIS to authenticate the user. In IIS, you can specify the security settings by right clicking on the Web site name and choosing properties, and then choosing the Directory Security tab. Finally, under the Anonymous Access and Authentication Control heading, click the Edit button. This will prompt you with a dialog box similar to the one on the right.
If Anonymous Access is checked, anonymous visitors may visit your site, and, with ASP.NET, they will use the account specified in the
machine.config. If the Basic Authentication option is checked, when the Web server attempts to authorize a user it will prompt them for their username/password. The Integrated Windows authentication option only works with Internet Explorer, but is a more secure authentication method since no passwords are transmitted between the client and the Web server. To get the ASP.NET example working you will need to have either (or both) Basic Authentication and Integrated Windows authentication checked.
<identity impersonate="true" />- This setting informs ASP.NET that when a user attempts to access some system resource (such as a file, or the performance monitor's data), to have the Web request perform its task as if an actual logged on user who has a Windows account on the Web server (or Web server's domain) initiated the task.
<authorization> <deny users="?" /> </authorization>- This setting informs ASP.NET that no anonymous users can access any resources within the directory that this
Essentially what this security arrangement allows is as follows: no anonymous users will be allowed to
access any ASP.NET Web pages in our directory (due to the
If an anonymous user attempts to access a page in our directory, they will be prompted by IIS to supply
their Windows username/password (they may not be prompted to do this if Integrated Windows authentication
is selected and the user is already logged onto the Web server's domain). Once the user enters an
appropriate username/password, they will be shown the page they requested.
The ASP.NET Web page we wish to present to the user is one that slurps down performance counter data. So, while all users who have Windows accounts on the Web server's domain will be able to access the performance counter ASP.NET Web page, only those with adequate permissions will be able to view the performance counter data (those with inadequate permissions will get the Access denied exception mentioned earlier).
In Part 2 we will (finally) examine how to create an ASP.NET Web page that can access performance counter data.