Free e-book: Windows 7 troubleshooting tips
Mitch Tulloch, a Microsoft Most Valuable Professional and lead author of the just-published
(and hot-selling) Windows
7 Resource Kit (Microsoft Press, 2010; ISBN: 9780735627000; 1760 pages),
has created a short e-book called “What You Can Do Before You Call Tech Support.”
Here are the opening paragraphs:
Your sound card has stopped working, your computer seems sluggish, the network is
down, your hard drive is clicking, you can’t view a website, your monitor is hard
to read, your new webcam isn’t working, your favorite program won’t run, and a funny
burning smell is coming from your computer. What can you do on your own to try to
troubleshoot the issue before you pick up the phone to call tech support?
If you’re running Windows 7, quite a lot. Microsoft has included a lot of self-support
tools in Windows 7 that you can try using before you seek the help of others, and
we’ll examine these in a moment. Then there are the tools you were born with—your
five senses (see, hear, smell, taste, touch) and most importantly your brain. And
by brain I’m including your memory, experience, and capacity for logical reasoning.
Finally, there is ancient and sacred lore passed on in secret from Master to Disciple
over the millennia. We’ll see shortly how your brain, your senses, and the secrets
of the Wise Ones can be very helpful for troubleshooting computer problems. But first
let’s look at what troubleshooting tools are built into Windows 7.
You can download the e-book in XPS
format here and in PDF
format here. Enjoy!
In my previous post I started a list of best practices that should be followed for
deploying applications to production systems. This is continuation of that post.
Create new Virtual Application in IIS
Right-click [website app will live in] > Create Application
Creating a new application provides each ASP.NET application its own sandbox environment.
The benefit to this is that site resources do not get shared between applications.
It is a requirement for all new web applications written in ASP.NET.
Create a new application pool for Virtual App
Right click on Application Pools and select Add Application Pool
Define name: “apAppName” - ‘ap’ followed by the Application Name
Set Framework version to 2.0
Set the Managed Pipeline mode: Most applications should use the default setting
An application pool is a distinct process running on the web server. It segregates
processes and system resources in an attempt to prevent errant web applications from
allocating all system resources. It also prevents any nasty application crashes from
taking the entire website down. It is also necessary for creating distinct security
contexts for applications. Setting this up is essential for high availability.
Set the memory limit for application pool
There is a finite amount of available resources on the web servers. We do not want
any one application to allocate them all. Setting a reasonable max per application
lets the core website run comfortably and allows for many applications to run at any
given time. If it is a small lightweight application, the max limit could be set lower.
Create and appropriately use an app_Offline.htm file
Friendlier than an ASP.NET exception screen (aka the Yellow Screen of Death)
If this file exists it will automatically stop all traffic into a web application.
Aptly named, it is best used when server updates occur that might take the application
down for an extended period of time. It should be stylized to conform to the application
style. Best practice is to keep the file in the root directory of the application renamed
to app_Online.htm, that way it can easily be found if an emergency update were to
Don’t use the Default Website instance
This should be disabled by default
Either create a new website instance or create a Virtual Application under existing
Numerous vulnerabilities in the wild make certain assumptions that the default website
instance is used, which creates reasonably predictable attack vectors given that default
properties exist. If we disable this instance and create new instances it will mitigate
a number of attacks immediately.
Create two Build Profiles
One for development/testing
One for production
Using two build profiles is very handy for managing configuration settings such as
connection strings and application keys. It lessens the manageability issues associated
with developing web applications remotely. This is not a necessity, though it does
make development easier.
Don’t use the wwwroot folder to host web apps
Define a root folder for all web applications other than wwwroot
As with the previous comment, there are vulnerabilities that use the default wwwroot
folder as an attack vector. A simple mitigation to this is to move the root folders
for websites to another location, preferably on a different disk than the Operating
These two lists sum up what I believe to be a substantial set of best practices for
application deployments. The intent was not to create a list of best development
best practices, or which development model to follow, but as an aid in strictly deployment.
It should be left to you or your department to define development models.
In the previous post Make it Right I
asked the question
Why aren’t more people making it right?
I was curious why people don’t take the time to write software properly. There
are lots of jokes about bad software development:
If houses were built the same way programmers build programs, we’d all be living on
Unfortunately it’s a fair statement. Most programs out there suck*. I
used to come back with the argument that people have been building houses for thousands
of years, but software for only a few decades. There are bound to be issues.
But then it occurred to me.
Mike Holmes is all about making it right, as I said in the previous post. His
TV show was about fixing the problems that professionals made. Professionals
who have been building the same thing people have built for thousands of years.
Wait a minute. I just flawed my own argument.
Houses are built the same way programmers build programs.
I see three very apparent reasons.
Cheapness – People want software built quickly, as cheap as possible.
Laziness – Why strain your mental processing or follow best practices when you can
just do whatever first comes to mind?
Uneducated – Sometimes (a lot of times) the person doing the building/development
just doesn’t know what they are doing.
There are numerous other reasons why, but these three are by far the biggest across
all aspects of building stuff. I think they answer the basic question asked
earlier, but now I have another question.
Why do we let people who are lazy or uneducated build applications for us, just so
we can save a few bucks? We will end up paying loads more in support after the
*I said programs, not programmers.