Windows Perfomance Troubleshooting

http://labmice.techtarget.com/troubleshooting/PerfMon.
htm
http://www.howtogeek.com/howto/6152/use-advanced-tools-to-troubleshoot-
performance-problems-in-windows-7/
http://www.techradar.com/news/software/operating-systems/slow-pc-how-to-find-out-
why-and-fix-it-914562
https://social.technet.microsoft.com/wiki/contents/articles/10128.tools-for-
troubleshooting-slow-boots-and-slow-logons-sbsl.aspx
https://technet.microsoft.com/en-us/library/cc749249(v=ws.11).aspx
https://technet.microsoft.com/en-us/library/dd744567(v=ws.10).aspx
https://www.smartertools.com/blog/2016/07/15-configure-perfmon-to-prevent-disk-issues
https://pal.codeplex.com/
https://msdn.microsoft.com/en-us/library/aa373083(v=VS.85).aspx
http://www.computerperformance.co.uk/win8/windows8-performance-monitor.htm
http://www.joekern.com/static/Server_Performance_Monitoring.pdf
https://www.winhelp.us/troubleshoot-performance-in-windows-vista-and-7.html
(https://www.winhelp.us/disable-visual-effects-in-windows.html)
Procmon
Lesson 3: Using Process Explorer to Troubleshoot and Diagnose
Understanding how Process Explorer’s dialogs and options work is all fine and good, but
what about using it for some actual troubleshooting or to diagnose a problem? Today’s
Geek School lesson will try and help you learn how to do just that.
SCHOOL NAVIGATION
1. What Are the SysInternals Tools and How Do You Use Them?
2. Understanding Process Explorer
3. Using Process Explorer to Troubleshoot and Diagnose
4. Understanding Process Monitor
5. Using Process Monitor to Troubleshoot and Find Registry Hacks
6. Using Autoruns to Deal with Startup Processes and Malware
7. Using BgInfo to Display System Information on the Desktop
8. Using PsTools to Control Other PCs from the Command Line
9. Analyzing and Managing Your Files, Folders, and Drives
10. Wrapping Up and Using the Tools Together
Not that long ago, we started investigating all sorts of malware and crapware that gets
installed automatically any time you don’t pay attention while installing software. Nearly
every piece of freeware on the market, including the “reputable” ones, are bundling
toolbars, search hijacking awfulness, or adware, and some of it is hard to troubleshoot.
We’ve seen many computers from people that we know that have so much spyware and
adware installed that the PC barely even loads anymore. Trying to load the web browser,
especially, is nearly impossible, as all of the adware and tracking software competes for
resources to steal your private information and sell it to the highest bidder.
So naturally, we wanted to do a bit of investigation into how some of these work, and
there’s no better place to start than the Conduit Search malware that has claimed hundreds
of millions of computers worldwide. This nefarious awfulness hijacks your search engine in
your browser, changes your home page, and most annoyingly, it takes over your New Tab
page no matter what your browser is set to.
We’ll start with looking at that, and then we’ll show you how to use Process Explorer to
troubleshoot errors that talk about locked files and folders that are in use.
And then we’ll round it out with another look at how some adware these days are hiding
themselves behind Microsoft processes so they appear legit in Process Explorer or Task
Manager, even though they really aren’t.
Investigating the Conduit Search Malware
As we mentioned, the Conduit search hijacker is one of the most persistent, awful, and
terrible things that nearly every one of your relatives probably has on their computer. They
bundle their software in shady ways with any freeware they can, and in many instances,
even if you select to opt-out, the hijacker will still be installed.
Conduit installs what they call “Search Protect”, which they claim prevents malware from
making changes to your browser. What they don’t mention is that it also prevents you from
making any changes to their browser unless you use their Search Protect panel to make
those changes, which most people won’t know about since it’s buried in the system tray.
Not only will Conduit redirect all of your searches to their own custom Bing page, it will set
that as your home page. One would have to assume that Microsoft is paying them for all
this traffic to Bing, since they are also passing some ?pc=conduit type of arguments in the
query string.
Fun fact: the company behind this piece of garbage is worth 1.5 Billion dollars and JP
Morgan invested $100 million into them. Being evil is profitable.
Conduit Hijacks the New Tab Page… But How?
Hijacking your search and home page is trivial for any malware — this is where Conduit
steps up the evil and somehow rewrites the New Tab page to force it to show Conduit, even
if you change every single setting.
You can uninstall all of your browsers, or even install a browser you didn’t have installed
before, like Firefox or Chrome, and Conduit will still manage to hijack the New Tab page.
Somebody should be in jail, but they are probably on a yacht.

It doesn’t take much in terms of geek skills to eventually deduce that the problem is the
Search Protect application running in the system tray. Kill that process, and suddenly your
new tabs open just the way the browser maker intended.
But how, exactly, does it do this? There are no add-ons or extensions installed into any of
the browsers. There aren’t any plugins. The registry is clean. How do they do it?
This is where we turn to Process Explorer to do some investigation. First, we’ll find the
Search Protect process in the list, which is easy enough because it is properly named, but if
you weren’t sure, you can always open up the window and use the little bulls-eye icon next
to the binoculars to figure out which process belongs to a window.
Now you can simply select the appropriate process, which in this case was one of the three
that run automatically by the Windows Service that Conduit installs. How did I know that it
was a Windows Service that restarts it? Because the color of that row is pink, of course.
Armed with that knowledge, I could always go stop or delete the service (though in this
particular case, you can simply uninstall from Uninstall Programs in Control Panel).
Now that you’ve selected the process, you can use the CTRL + H or CTRL + D shortcut keys to
open the Handles view or the DLLs view, or you can use the View -> Lower Pane View menu
to do it.
Note: in the world of Windows, a “handle” is an integer value that is used to uniquely
identify a resource in memory like a window, an open file, a process, or many other things.
Each open application window on your computer has a unique “window handle”, for
example, that can be used to reference it.
DLLs, or dynamic link libraries, are shared pieces of compiled code that are stored in a
separate file to be shared among multiple applications. For instance, instead of having every
application write their own File Open / Save dialogs, all applications can simply use the
common dialog code provided by Windows in the comdlg32.dll file.
Looking through the list of handles for a few minutes brought us a little bit closer to what
was going on, because we found handles to Internet Explorer and Chrome, both of which
are currently open on the test system. We’ve definitely confirmed that Search Protect is
doing something to our open browser windows, but we’ll need to do a little more research
to figure out exactly what.
The next thing to do is double-click the process in the list to open up the details view, and
then flip over to the Image tab, which will give you information about the full path to the
executable, the command line, and even the working folder. We’ll click the Explore button
to take a look at the installation folder and see what else is hiding there.
Interesting! We’ve found a number of DLL files here, but for some weird reason none of
these DLL files were listed in the DLL view for the Search Protect process when we were
looking at it earlier. This could be a problem.
Any time you want to see whether a DLL file is currently being used by any application on
your system, you can pop up the search pane by going to the Find menu, hitting CTRL + F, or
just clicking the binoculars icon on the toolbar. Now type in part of the name of the DLL, or
even the full name if you’d like.
We chose to search for just the beginning, “SPVC”, since that was the common tie between
them all, and sure enough, it looks like those DLLs are being loaded directly into each of the
browser processes running on our computer.
Clicking on one of the items in the list and switching over to the Threads page confirmed
what we were worried about. Both Chrome and Internet Explorer were running threads
using the SPVC32.dll or SPVC64.dll files from the Search Protect malware, and this is how
they were hijacking our new tab page — not by changing settings, but by hijacking the
browser from within.
Note: In Windows, a thread is what the operating system allocates processor time to run. A
process in Windows is what we’re used to thinking of as geeks and system admin types, but
technically threads are actually the only thing that runs in Windows, not processes. Certain
processes may have only one thread of execution, but others may have many threads that
are all running separately from one another, usually communicating with some sort of in-
process communication mechanism.
You can also double-click on any of the threads to see the full execution stack, which can be
useful to see what functions are being called and attempt to figure out what the problem is.
You might be wondering how the Search Protect application managed to get Google
Chrome to load that DLL, and the answer is that Windows provides a feature called DLL
Injection. A process can inject a DLL into another process, and then hijack certain API
functions. This is how certain applications override Windows features or features in other
applications. It’s a very complicated subject that we definitely can’t get into in this lesson,
but if you really want to read more, you can check out this guide.
It’s also worth noting that you can see the CPU usage per thread by digging into this level of
details, which can be very useful when troubleshooting an application that has plugins. You
could use this to figure out that a particular DLL file is taking up too much of the processor
time, and then do some research on what that component belongs to.
Dealing with Locked Files or Folders
Since it’s unlikely that you’ll be investigating malware all the time, it’s also helpful to use
Process Explorer for other tasks, like dealing with those “In Use” dialogs that you can any
time you try to delete or move or modify a file or folder that is being used by another
process, especially when you aren’t sure what process is locking it up.
When you get an error like that one, just head over to Process Explorer, open up the search
with CTRL + F or the icon, and then type in the name of the folder listed above (or more
descriptive full path if the name is very vague).
You’ll very quickly see a process in the list that has your file or folder open, and you can
double-click on it to identify the process in the list.
Your immediate reaction might be to just close that process, but you don’t necessarily have
to do that. You can also right-click on the file or folder in the list of handles (Use the CTRL +
H option to bring up the Handles list) and choose the Close Handle option. That resource is
now unlocked!
Note: If you’re deleting something, this is a perfectly fine option, but if you are just trying to
edit or move that item, you should probably open the offending application and deal with it
there so you don’t lose any data.
Researching Processes that Look Safe but Aren’t
During our malware research we’ve noticed another problem that is becoming more
prevalent, so it is wise to keep an eye on it in the future. What is that problem? Malware is
hiding behind legitimate Windows processes, and it’s doing a good job.
The problem is the Windows rundll32.exe utility, which can be used to arbitrarily run
functions from DLL files. Since this utility is signed by Microsoft it shows up as a completely
legit process in the list, but in reality what they are doing is just moving all of their malware
/ adware code into a .DLL file instead of a .EXE file, and then loading up the malware with
rundll32.exe instead. In fact, if you see rundll32.exe running as an “own process” in the light
blue color shown below, it’s nearly always something that shouldn’t be running.
In the example below, you can see that even though we used the Verified Signer feature to
validate that item, when we hover over it and look at the full path, it is actually loading up a
DLL that turns out to be part of an adware product.
Note: before you start screaming about running an anti-virus scan, we’ll note that we did,
and it didn’t come back with anything. Much of this crapware, adware, and spyware is
ignored by anti-virus utilities.
Double-clicking to open up the details shows more of the problem, and we can also see the
directory that the badware is running out of, which we’ll use to investigate further.
Inside that directory we found a number of files that were being updated constantly in the
background.
The rest of the investigation led into some other tools that weren’t SysInternals, and that
we’ll probably cover at a later date, but suffice it to say that this is just a piece of malware
that was running in conjunction with another crapware application.
The important point here is that malware is able to hide itself behind legitimate Windows
executables, so be sure to keep your eyes peeled for anything similar.
Coming Up Next
Stay tuned tomorrow for even more SysInternals knowledge, as we show you how to use
the Process Monitor utility to track what applications are actually doing behind the scenes.
It’ll be eye-opening.
Lesson 4: Understanding Process Monitor
Today in this edition of Geek School we’re going to teach you about how the Process
Monitor utility allows you to peek under the hood and see what your favorite applications
are really doing behind the scenes — what files they are accessing, the registry keys they
use, and more.
SCHOOL NAVIGATION
Unlike the Process Explorer utility that we’ve spent a few days covering, Process Monitor is
meant to be a passive look at everything that happens on your computer, not an active tool
for killing processes or closing handles. This is like taking a peek at a global logfile for every
single event that happens on your Windows PC.
Want to understand which registry keys your favorite application is actually storing their
settings in? Want to figure out what files a service is touching and how often? Want to see
when an application is connecting to the network or opening a new process? It’s Process
Monitor to the rescue.
We don’t do a lot of registry hack articles anymore, but back when we first started we
would use Process Monitor to figure out what registry keys were being accessed, and then
go tweak those registry keys to see what would happen. If you’ve ever wondered how some
geek figured out a registry hack that nobody has ever seen, it was probably through Process
Monitor.
The Process Monitor utility was created by combining two different old-school utilities
together, Filemon and Regmon, which were used to monitor files and registry activity as
their names imply. While those utilities are still available out there, and while they might
suit your particular needs, you’d be much better off with Process Monitor, because it can
handle a large volume of events better due to the fact that it was designed to do so.
It’s also worth noting that Process Monitor always requires administrator mode because it
loads a kernel driver under the hood to capture all of those events. On Windows Vista and
later, you’ll be prompted with a UAC dialog, but for XP or 2003, you’ll need to make sure the
account you use has Administrator privileges.
The Events that Process Monitor Captures
Process Monitor captures a ton of data, but it doesn’t capture every single thing that
happens on your PC. For instance, Process Monitor doesn’t care if you move your mouse
around, and it doesn’t know whether your drivers are working optimally. It’s not going to
track which processes are open and wasting CPU on your computer — that’s the job of
Process Explorer, after all.
What it does do is capture specific types of I/O (Input / Output) operations, whether they
happen through the file system, registry, or even the network. It will additionally track a few
other events in a limited fashion. This list covers the events that it does capture:
 Registry – this could be creating keys, reading them, deleting them, or querying
them. You’ll be surprised just how often this happens.
 File System – this could be file creation, writing, deleting, etc, and it can be for both
local hard drives and network drives.
 Network – this will show the source and destination of TCP/UDP traffic, but sadly it
doesn’t show the data, making it a bit less useful.
 Process – These are events for processes and threads where a process is started, a
thread starts or exits, etc. This can be useful information in certain instances, but is
often something you’d want to look at in Process Explorer instead.
 Profiling – These events are captured by Process Monitor to check the amount of
processor time used by each process, and the memory use. Again, you would
probably want to use Process Explorer for tracking these things most of the time, but
it’s useful here if you need it.
So Process Monitor can capture any type of I/O operation, whether that happens through
the registry, file system, or even the network — although the actual data being written isn’t
captured. We’re just looking at the fact that a process is writing to one of these streams, so
we can later figure out more about what is happening.
The Process Monitor Interface
When you first load up the Process Monitor interface, you’ll be presented with an enormous
number of rows of data, with more data flying in quickly, and it can be overwhelming. The
key is to have some idea, at least, about what you are looking at, as well as what you are
looking for. This isn’t the type of tool that you spend a relaxing day browsing through,
because within a very short time period, you’ll be looking at millions of rows.
The first thing you’ll want to do is filter those millions of rows down to the much smaller
subset of data you want to see, and we’re going to teach you how to create filters and zero
in on exactly what you want to find. But first, you should understand the interface and what
data is actually available.
Looking at the Default Columns
The default columns show a ton of useful information, but you’ll definitely need some
context to understand what data each one actually contains, because some of them might
look like something bad happened when they are really innocent events that happen all the
time under the hood. Here’s what each of the default columns is used for:
 Time – this column is fairly self-explanatory, it shows the exact time that an event
occurred.
 Process Name – the name of the process that generated the event. This doesn’t
show the full path to the file by default, but if you hover over the field you can see
exactly which process it was.
 PID – the process ID of the process that generated the event. This is very useful if
you are trying to understand which svchost.exe process generated the event. It’s
also a great way to isolate a single process for monitoring, assuming that process
doesn’t re-launch itself.
 Operation – this is the name of the operation that is being logged, and there is an
icon that matches up with one of the event types (registry, file, network, process).
These can be a little confusing, like RegQueryKey or WriteFile, but we’ll try and help
you through the confusion.
 Path – this is not the path of the process, it is the path to whatever was being
worked on by this event. For instance, if there was a WriteFile event, this field will
show the name of the file or folder being touched. If this was a registry event, it
would show the full key being accessed.
 Result – This shows the result of the operation, which codes like SUCCESS or ACCESS
DENIED. While you might be tempted to automatically assume that an BUFFER TOO
SMALL means something really bad happened, that isn’t actually the case most of
the time.
 Detail – additional information that often doesn’t translate into the regular geek
troubleshooting world.
You can also add some additional columns to the default display by going to Options ->
Select Columns. This wouldn’t be our recommendation for your first stop when you start
testing, but since we’re explaining columns, it’s worth mentioning already.
One of the reasons for adding additional columns to the display is so you can very quickly
filter by those events without being overwhelmed with data. Here are a few of the extra
columns that we use, but you might find use for some others in the list depending on the
situation.
 Command Line – while you can double-click on any event to see the command line
arguments for the process that generated each event, it can be useful to see at a
quick glance all of the options.
 Company Name – the main reason that this column is useful is so you can simply
exclude all Microsoft events quickly and narrow down your monitoring to everything
else that isn’t part of Windows. (You’ll want to make sure that you don’t have any
weird rundll32.exe processes running using Process Explorer though, since those
could be hiding malware).
 Parent PID – this can be very useful when you are troubleshooting a process that
contains many child processes, like a web browser or an application that keeps
launching sketchy things as another process. You can then filter by the Parent PID to
make sure that you capture everything.
It’s worth noting that you can filter by column data even if the column isn’t showing, but it’s
much easier to right-click and filter than manually do it. And yes, we mentioned filters again
even though we haven’t explained them yet.
Examining a Single Event
Viewing things in a list is a great way to quickly see a lot of different data points at once, but
it definitely isn’t the easiest way to examine a single piece of data, and there is only so much
information you can see in the list. Thankfully you can double-click on any event to access a
treasure trove of extra information.
The default Event tab gives you information that is largely similar to what you saw in the list,
but will add a bit more information to the party. If you are looking at a file system event,
you’ll be able to see certain information like the attributes, file create time, the access that
was attempted during a write operation, the number of bytes that were written, and the
duration.
Switching over to the Process tab gives you lots of great information about the process that
generated the event. While you’ll generally want to use Process Explorer to deal with
processes, it can be very useful to have a lot of information about the specific process that
generated a specific event, especially if it is something that happened very quickly and then
disappeared from the process list. This way the data is captured.
The Stack tab is something that will sometimes be extremely useful, but often times will not
be useful at all. The reason why you would want to look at the stack is so you can
troubleshoot by examining the Module column for anything that doesn’t look quite right.
As an example, imagine that a process was constantly trying to query or access a file that
doesn’t exists, but you weren’t sure why. You could look through the Stack tab and see if
there were any modules that didn’t look right, and then research them. You might find an
out of date component, or even malware, is causing the problem.
Or, you might find that there isn’t anything useful here for you, and that’s just fine too.
There is a lot of other data to look at.
Notes on Buffer Overflows
Before we even proceed further, we’re going to want to note a result code that you’re going
to start seeing a lot in the list, and based on all your geek knowledge so far, you might freak
out a little bit about. So if you start seeing BUFFER OVERFLOW in the list, please don’t
assume that somebody is trying to hack your computer.
Lesson 4: Understanding Process Monitor
Buffer Overflows
While yes, many hackers and malware creators exploit a buffer overflow weakness to
remotely or locally hack into a component and gain extra access, this error message is
actually built into the Windows API and means the complete opposite.
Note: Imagine a buffer like a box of candy bars near the register in a grocery store. People
keep buying them, and when the box gets low, the store fills the box again.
Ideally they won’t wait for the box to be empty, because that would be frustrating for
customers, and they also will ideally not go running to the back every single time a customer
buys a single candy bar, because that would be a waste of time. This is a buffer, and they are
meant to prevent delays.
What the BUFFER OVERFLOW message in the Windows API, and specifically in Process
Monitor, actually mean is that the client application requested data but didn’t have a large
enough bucket to hold all of the data. So the server is responding to tell the client that they
need a bigger bucket.
In the example for the screenshot above, the application queried the registry for a specific
value, but told the Windows API to put the result into a place in memory that was too small
to fit all that data. So Windows returned back the message to let the application know that
they need a bigger spot to put all the data. That’s all it was.
Jumping to an Event Data Path
All of this information is really great, but nobody wants to investigate by manually browsing
to each and every location in the list. Luckily you can right-click on the Path field for an item
and use the Jump To option to quickly access that data to see what it contains and try to
figure out why the application is requesting that data in the first place.
Note: you can also use the Search Online feature to quickly search for the name of the
process, the registry path, or any other field, which can be really useful when you don’t
understand what something is used for.
In the example above, you can see that the application we were monitoring was trying to
look at a registry value, so we used the Jump To feature, and Process Monitor immediately
opened the Registry Editor already focused to that exact key.
So now we know, the application is trying to figure out where my appdata folder is, and we
know which folder that was… which helps explain what is going on.
In this case, the application was the Conduit search malware, and it was looking for my user
folder by querying the regisry so that it could start messing around with files and folders
inside of my Google Chrome profile.
Filtering the Data that Process Monitor Captures
As we’ve mentioned a couple of times already, the filters that Process Monitor provides
allow you fine-grained control over what events you are going to be capturing, which
translates into much easier work for you to figure out what is important in the list. If you
know that you don’t care about all of the events generated by explorer.exe, for example,
then you would be wise to just filter them out.
You can very quickly filter by any column using the context menu and using the Include or
Exclude features — if you Include an item, the list will only contain events that match that
particular item, or any others that you specifically include, but will not contain anything else.
If you Exclude an item, everything will show up except for events that match the very
specific item that you excluded.
In this case we decided to Include the cltmng.exe process, and now every single thing that
we see in the list is related to that process.
You can alternatively use the Edit Filter option from the menu, or access the Filters section
of the menu to display the list of filters and edit them. You can choose from the drop-down
dialogs and match by any of the available fields, choose whether the value you type into the
box will be matched exactly, or just “starts with”, or a number of other options. Then you
can choose whether to Include or Exclude events that match those criteria.
Just don’t forget to click the Add button once you’ve defined your filter and before you click
OK or Apply, because otherwise your new filter won’t actually be activated. Trust us, this is a
common mistake!
You can also remove or edit filters by selecting them in the list and then modifying or
removing them.
Way Too Much Data? Try Dropping Filtered Events
If you know for sure that you have the right filters to look at just the things you really want
to see, you might want to consider using the Filter -> Drop Filtered Events feature.
What’s actually going on here is that the instance of Process Monitor is showing only the
items that match the filter, but everything else is still being captured in the background,
which can be a TON of data after a very short time — note the status bar in the example
below that we had running for just a few minutes. If we had the Drop Filtered Events option
turned on, it would have only captured just the events we wanted.
There is a big drawback to using this feature though, and that is that you can’t get back
those filtered events if you realized you filtered the list by too much, and wanted to
examine events from another process. You’d have to redo your entire scenario, which might
be too late. So make sure to use this option with caution.
Saving Dumps for Later Analysis
There’s one last thing for today’s lesson, and that is the Open / Save feature that we
normally wouldn’t highlight on any other application, but in this case it is really important.
Imagine you are working on somebody’s really old and lousy computer, and you want to
diagnose a particular problem, but the computer is just running way too slow to sit there
and deal with it the entire time. You can simply run a Process Monitor scan on their
computer, save the data over to a flash drive, and then load up Process Monitor on your
blazing fast personal laptop and get to work analyzing what might have happened. You can
even go to the coffee shop and analyze from there.
And of course, you could also just remotely talk somebody through running Process
Monitor, doing a scan, saving the file, and then sending it to you for analysis. That way you
don’t even have to show up and see them in person.
Next Lesson
Stay tuned for tomorrow’s lesson, where we will put together all of the knowledge that
we’ve gained and show how to use Process Monitor in the real world to accomplish some
fun and interesting things.
https://www.howtogeek.com/school/sysinternals-pro/lesson5/all/
In today’s edition of Geek School we’re going to teach you how to use Process Monitor to
actually accomplish troubleshooting and figuring out registry hacks that you would not
know about otherwise.
SCHOOL NAVIGATION
Process Monitor is one of the most impressive tools that you can have in your toolkit, as
there is almost no other way to see what an application is actually doing under the hood. It
is the only way to know what files are being written to by which process, and where things
are stored in the registry, and which files are accessing them.
We’ll start off with today’s lesson by looking at how to find registry keys using Windows
setting dialogs and Process Monitor, and then we’ll go through an actual troubleshooting
scenario that we encountered on one of our computers in the lab, and easily solved using
Process Monitor.
Using Process Explorer to Find Registry Keys for Common Settings
Everybody has clicked a checkbox or changed the value of a drop-down box at some point,
but have you ever wondered where those values are actually stored? Many applications,
and virtually everything in Windows, is stored in the Registry… somewhere.
For today’s example we’re going to use the first option on the first pane of Taskbar and
Navigation Properties, which is a dialog that should exist in all versions of Windows. So now
our mission is to figure out where that setting is actually stored in the registry. You can
follow along with this particular setting, or you can try one of the other settings on the same
dialog — or anywhere else you’d like to find the hidden setting location for.
The first thing you’ll want to do whenever trying to capture a set of data is to launch Process
Monitor, and then change the setting. At that point you can stop Process Monitor from
continuing to capture events, so the list doesn’t get out of control. (Hint: the File menu has
the option, or it’s the third icon from the left).
Now that we’ve got a ton of data in the list, it’s time to filter the list to reduce the number
of rows that we’re going to have to look through. Since we’re looking at a registry value that
is being changed, we’ll need to filter by “RegSetValue”, which is what Windows uses to
actually set a registry key to a new setting. Use the “Include” option to show only those
events.
Your list should now be limited to just registry keys that were changed, so it’s time to take a
look at the events and try to figure out which registry key it might be. Since we’re checking
the “Lock the Taskbar” setting, and one of the registry keys being set includes the word
“Taskbar” in the name, that’s a good place to start. Right-click on the path and choose to
Jump To the location.
Process Monitor will open up the Registry Editor and highlight the key in the list. Now we
need to make sure that this is actually the right key, which is pretty easy to figure out. Take
a look at the setting, and then take a look at the key. Right now the setting is on, and the
key is set to 0.
So change the setting, hit Apply on the dialog, and then use the F5 key to refresh the
Registry Editor window. In our case we definitely picked the right setting, so now you can
see that the TaskbarSizeMove value is set to 1.
If you didn’t pick the right value, you won’t see a change when you do the setting test again.
So go and find the next logical one, and start over.
Troubleshooting Problems with Process Monitor
It’s not really possible to illustrate in a single article how to troubleshoot any problem with
Process Monitor, or any other tool for that matter. There are just way too many
combinations of issues that could possibly go wrong.
What we can do, however, is show how we actually used Process Monitor to troubleshoot a
real problem that actually happened to one of our test computers. We had been installing
some crapware, and then decided to try and clean the computer up. The problem was an
entry in the Uninstall Programs panel that just wouldn’t go away.
Every time you would click to Change so you could remove it, you’d get an error that said
“An error occurred while trying to uninstall AwfulApp. It may have already been uninstalled.
Would you like to remove AwfulApp from the Programs and Features list?”.
That would have been great, except we then got an error that said “You do not have
sufficient access to remove OutfoxTV from the Programs and Features list. Please contact
your system administrator.”
The first thing to do was try the uninstall process again with Process Monitor running, which
captured an enormous amount of data. This time we decided to use the Find feature (CTRL +
F) to quickly find what we were looking for in the list. You could also use a Filter if you
wanted, but this seemed simple, and luckily it worked the first time.
After taking a look at the first item in the list, we noticed an error: Windows was attempting
to access the registry keys related to the uninstaller, but they weren’t actually in the registry
in the first spot that Windows was looking. If you look a couple of keys down though, you’ll
see a RegOpenKey event with a SUCCESS result for something under
HKLM\Software\Wow6432Node.
Doing a search by that registry key very quickly landed us at the source of the problem: an
ACCESS DENIED message when Windows tried to do the cleanup for the list using the
RegDeleteKey operation. Interesting!
The first thing to do was use the Jump To feature to find the key in the registry and take a
look.
Sure enough, look at all those registry keys over there! No wonder it is still appearing in the
list.
Just to be sure, we opened up the C:\Program Files\ directory to see if any of the files were
still around, but clearly the app had been wiped off the PC already.
The solution was very simple: we just manually deleted the registry key that Windows had
problems deleting. If we had received an access denied message, we could have used the
Permissions setting to make sure that we have access and tried again.
Luckily the delete worked immediately, and our Uninstall Programs list was now clear.
These are just a few of the many ways that you can use Process Monitor – it is an extremely
important and useful utility that will take some time to master, but once you do, it can really
help you solve many problems.
Next Lesson
Starting on Monday with the next lesson, we’ll examine many of the other utilities in the
SysInternals Toolkit, including some of the powerful command line tools.
Most geeks have their tool of choice to deal with processes that start up automatically,
whether that is MS Config, CCleaner, or even Task Manager in Windows 8 — but none of
them are as powerful as Autoruns, which is also our Geek School lesson for today.
SCHOOL NAVIGATION
In the olden days, software would start itself automatically by adding an entry to the Startup
folder in the Start Menu, or adding a value into the Run key in the registry, but as people
and software became more savvy at finding unwanted entries and deleting them, the
makers of questionable software started finding ways to get more and more sneaky.
These shady crapware companies started figuring out how to automatically load their
software through browser helper objects, services, drivers, scheduled tasks, and even
through some extremely advanced techniques like image hijacks and AppInit_dlls.
Checking for each of these conditions manually would not only be time-consuming, but
nearly impossible to do for the average person.
That’s where Autoruns comes in and saves the day. Sure, you can use Process Explorer to
look through the process list and delve deep into threads and handles, and Process Monitor
can figure out exactly which registry keys are being opened by which process and show you
incredible amounts of information. But neither one stops crapware or malware from being
loaded again the next time you boot your PC.
Of course, a smart strategy would be to use all three together. Process Explorer sees what is
currently running and using up your CPU and memory, Process Monitor sees what the
application is doing under the hood, and then Autoruns comes in to clean things up so they
don’t come back.
Autoruns allows you to see nearly every single thing that is loaded automatically on your
computer, and disable it as easy as clicking a checkbox. It’s incredibly easy to use, and nearly
self-explanatory, except for some of the really complicated things you need to know to
understand what some of the tabs actually mean. That’s what this lesson is going to teach.
Working With the Autoruns Interface
You can grab the Autoruns tool from the SysInternals web site just like all of the rest and run
it without installing. You’ll want to do that before proceeding.
Note: Autoruns doesn’t require running as administrator, but realistically it makes the most
sense to just do that, since there are a few features that won’t work as well otherwise, and
there’s a good chance your malware is running as administrator as well.
When you first launch the interface you’ll see a ton of tabs and a list of things that are being
started automatically on your computer. The default Everything tab shows everything from
every tab, but it can be a little confusing and lengthy, so we’d advise to just go through each
tab separately.
It’s worth noting that by default, Autoruns hides everything that is built into Windows and
set to automatically start. You can enable showing of those items in the options, but we
wouldn’t recommend it.
Disabling Items
To disable any item in the list, you can just remove the check box. That’s all you have to do,
just go through the list and remove everything you don’t need, reboot your computer, and
then run it again to make sure everything is good.
Note: some malware will constantly monitor the locations where they trigger autostart
from, and will immediately put the value back. You can use the F5 key to rescan and see if
any of the entries came back after disabling them. If one of them showed up again, you
should use Process Explorer to suspend or kill that malware before disabling it here.
The Colors
Like most SysInternals tools, the items in the list can be different colors, and here is what
they mean:
 Pink – this means that no publisher information was found, or if code verification is
on, means that the digital signature either doesn’t exist or doesn’t match, or there is
no publisher information.
 Green – this color is used when comparing against a previous set of Autoruns data to
indicate an item that wasn’t there last time.
 Yellow – the startup entry is there, but the file or job it points to doesn’t exist
anymore.
Also just like most of the SysInternals tools, you can right-click on any entry and perform a
number of actions, including jumping to the entry or image (the actual file in Explorer). You
can search online for the name of the process or the data in the column, see the detailed
properties, or see if that entry is running by doing a quick search through Process Explorer
— although many processes have a loader that then launches something else before exiting,
so just because that feature shows no results doesn’t mean anything.
If you clicked Jump to Entry, you’ll be taken straight over to the Registry Editor, where you
can see that particular registry key and look around. If the entry was something else, you
might be taken to a different utility, like the Task Scheduler. The reality is that most of the
time, Autoruns displays all of the same information right in the interface, so you don’t
usually need to bother unless you want to learn more.
The User menu allows you to analyze a different user account, which can be really useful if
you’ve loaded up Autoruns on a different account on the same computer. It’s worth noting
that you would obviously need to be running as administrator to see other user accounts on
the PC.
Verifying Code Signatures
The Filter Options menu item takes you to an options panel where you can select one very
useful option: Verify Code Signatures. This will check to make sure that each digital
signature is analyzed and verified, and display the results right in the window. You’ll notice
that all the items in pink in the screenshot below are not verified or the publisher
information does not exist.
And for extra credit, you might notice that this screenshot below is almost the same as the
one near the beginning, except in that one some of the items in the list where not marked
as pink. The difference is that by default without the Verify Code Signatures option turned
on, Autoruns will only alert you with the pink row if no publisher information exists.
Analyze an Offline System (As in Hooking Up a Hard Drive to Another PC)

Imagine that your friend’s computer is completely messed up and either won’t boot or just
boots so slowly that you can’t really use it. You’ve tried safe mode and recovery options like
System Restore, but it doesn’t matter because it is unusable.
Rather than pull the “reinstall” card, which is often just the “I give up” card, you could yank
out the hard drive and hook it up to your PC or laptop with your handy USB hard drive dock.
You do have one, right? Then you just load up Autoruns and go to File -> Analyze Offline
System.
Browse to find the Windows directory on the other hard drive, and the user profile of the
user you are trying to diagnose, and click OK to start.
You’ll need write access to the drive, of course, because you will want to save the settings to
remove whatever nonsense you end up finding.
Comparing Against Another PC (Or Previous Clean Install)
The File -> Compare option seems nondescript, but it can be one of the most powerful ways
to analyze a PC and see what has been added since the last time you scanned, or to
compare against a known clean PC.
To use this feature, just load up Autoruns on the PC you are trying to inspect, or using the
Offline mode we described earlier, then head to File -> Compare. Everything that has been
added since the compared file version will show up in bright green. It’s as simple as that. To
save a new version, you’d use the File -> Save option.
If you really want to be a pro, you could save a clean configuration from a new install of
Windows and put that on a flash drive to take with you. Save a new version every time you
touch a PC for the first time to make sure you can quickly identify all of the new crapware
the owner has added.
Looking at the Tabs
As you’ve seen so far, Autoruns is a very simple but powerful utility that could probably be
used by almost anybody. I mean, all you have to do is uncheck a box, right? It is, however,
useful to have some more information about what all of these tabs mean, so we’ll try and
educate you here.
Lesson 6: Using Autoruns to Deal with Startup Processes and Malware
Logon
This tab checks all of the “normal” locations in Windows for things to automatically be
loaded, including the Registry’s Run and RunOnce keys, the Start Menu… and a lot of other
places. As it turns out, there are 43 different “normal” places that software can insert itself
to start up automatically at logon or logoff. No wonder there are such huge malware,
crapware, and spyware problems in Windows!
Our advice: liberally uncheck everything you don’t need. You can always re-enable it if you
want.
Explorer
This tab lists all of the add-on components that can load themselves into Windows Explorer.
Since we didn’t have any to illustrate on our test system, we won’t show you a screenshot,
but these will largely be context menu add-ons and other things like that.
If you are experiencing slow performance when browsing files, using the context menu, or
just all around Windows, this is a likely culprit. You can disable anything you feel like here,
though you might lose some functionality for certain applications.
Internet Explorer
This tab is immensely useful when working on other people’s computers, since they are
much more likely to be using Internet Explorer than our readers are. This tab lists out all of
the browser extensions, toolbars, and browser helper objects that are usually used by
malware to either spy on you or show you ads. We’d recommend unchecking just about
every single thing you see.
Scheduled Tasks
This is one of the trickiest ways that malware is hiding itself these days. Rather than hide
using any of the places that people know to look for, the malware creates a scheduled task
to reinstall itself, show ads, or do all sorts of nefarious things. The problem is compounded
by how confusing the Task Scheduler can be, so most people would never even know to look
here. Thankfully Autoruns makes this one easy.
We’d recommend removing almost everything that you don’t recognize and definitely isn’t
from Microsoft. This is one example where using the Verify Code Signatures option is really
useful.
Services
After tasks, one of the most common and insidious places that malware is hiding itself these
days is by registering a Service in Windows, or in some cases, by creating a service that helps
make sure that the other malware processes are still running.
You’ll want to be a little more careful when disabling things on this tab, as some things may
be legit and necessary. In the screenshot below, you’ll see some Google, Microsoft, and
Mozilla services that are just fine. While it wouldn’t be a big deal if we disabled them, it is
still worth doing some extra research before disabling things, unless you have identified it as
crapware or malware already.
Drivers
Believe it or not, but some crapware and malware makers have actually created device
drivers that contained malware or very sketchy components that spy on you. After our test
machine was infected with a bunch of crapware, we noticed that this driver showed up
attached to one of them. We’re still not quite sure what it does, but given how it got there,
it probably isn’t anything good.
You’ll definitely want to be much more careful on this screen. Disabling the wrong drivers
can break your computer, so do your research, right-click on each of them and search
online, and only disable something if it is most likely tied to spyware. In the example below,
we had already identified the folder in the Image Path for the highlighted row as being
crapware, so it was logical to disable it.
Codecs
These are libraries of code that are used to handle media playback for videos or audio, and
unfortunately they have been abused by malware as a way to automatically start on the
computer. You can disable them here if necessary.
Boot Execute
This one you probably won’t have to deal with, but it is used for things that start up during
system boot, like when you schedule a hard drive check to happen at boot time since it can’t
happen while Windows is actually loaded.
Image Hijack
If you read our second lesson about Process Explorer, you would have learned that you
can replace Task Manager with Process Explorer, but you probably had no idea how this
actually happens, much less that malware can and does use the same technique to hijack
applications on your computer.
You can set a number of settings in the registry that control how things are loaded,
including hijacking all executables and running them through another process, or even
assigning a “debugger” to any executable — even if that application is not a debugger.
Essentially, you can assign values in the registry so that if you try to load notepad.exe, it will
load calc.exe instead. Or any application can be swapped out and replaced with another
application. This is one of the ways that malware blocks you from loading MalwareBytes or
other anti-malware tools.
You can see it for yourself — on the left-hand side is the name of the executable, and on the
right-hand side the “Debugger” key is set to the instance of Process Explorer that is running
off my desktop. But you can change that to anything you want on either side and it will
work. It would probably make a great prank that almost nobody would ever be able to
figure out.
If you see anything in the Image Hijacks tab other than the values for Process Explorer, you
should immediately disable them.
AppInit
In yet another example of why Windows has so much crapware and spyware,
the AppInit_dlls entries in the registry are surprising and amazing. At some point Microsoft
wrote a feature into Windows that loads all DLL files listed in a particular registry key… into
every single process that starts.
Well, technically, whenever an application loads the Windows user32.dll library, it checks
the value of the registry key and then loads any of the DLLs found in the list into the process,
allowing every application to be hijacked by malware.
In Windows Vista and later versions, they finally decided to lock this down a little bit by
requiring that the DLLs be digitally signed… unless the RequireSignedAppInit_DLLs key is set
to 0, which makes Windows still load them anyway. As you can imagine, malware has taken
advantage of this, as you can see in the example below.
Remember back in lesson 3 when we showed you how Conduit was hijacking and inserting
its DLL files into your browser’s processes? This is how that was done. You can see the
spvc64loader.dll in the screenshot above, which was then used to load up the SPVC64.dll file
into the browser.
Evil.
KnownDLLs
This key makes sure that Windows uses a particular version of a DLL file. For the most part
you won’t need to worry about it unless malware has messed with this list — the primary
goal of using this tab is just to make sure that everything listed there is really a verified
Windows component, which is pretty easy.
Winlogon, Winsock Providers, Print Monitors, LSA Providers, Network Providers
You shouldn’t usually have to worry about these tabs, as they simply contain add-ons that
extend various aspects of Windows – the Winlogon and LSA tap into the logon and
authentication system, Winsock and Network handle networking, and Print Monitors are
third-party applications that deal with your printer.
If you do have values in these tabs, it is worthwhile to investigate before disabling them. It is
certainly possible for malware to hijack these things.
Sidebar Gadgets
If you have any sidebar gadgets in Vista or Windows 7, you will see them here, and you can
disable them if you’d like.
Next Lesson
That’s it for Autoruns, but stay tuned tomorrow when we teach you about Bginfo and
displaying system information on your desktop.
Lesson 7: Using BgInfo to Display System Information on the Desktop
If you have ever done system administration, you probably have the problem where you
connect to so many servers that you have no idea which computer you are connected to
half the time. BGInfo is a great utility that lets you display useful system information right on
the desktop. And it works for regular Windows users as well.
SCHOOL NAVIGATION
If you’ve been following along with our series, you might be surprised at the huge departure
from hunting malware and deleting crapware to displaying stuff on the desktop, but the
SysInternals tools aren’t just about finding things to kill. There are also many utilities in the
toolkit used for displaying information, and we’re going to look at some of them.
The BGInfo utility displays information on the desktop, and it works in a server environment
as well — in fact, that’s probably where it is the most useful, but it also works on anybody’s
computer, so you can test things out on your local machine before running the configuration
on the server.
You can also save information from BGInfo to a text file or even a database without even
displaying on the desktop, so if you are looking for a quick way to capture information on all
the computers in your network, you can use BGInfo and some batch scripts to solve your
problem.
It’s worth noting that BGInfo displays information by writing text over top of your wallpaper,
if you have wallpaper set. It will create a new wallpaper file and then assign that as your
new default wallpaper.
If this isn’t your cup of tea, make sure to read through the rest of the series and wait for
tomorrow’s lesson, when we’ll be discussing the very powerful set of PsTools provided by
SysInternals.
Using the BGInfo Interface
Using BGInfo is very simple: open it and click the Apply button, and your desktop will have a
ton of system information plastered all over it right away. If you want that information to
update regularly, we’ll need to add a shortcut to the startup folder, or create a scheduled
task to do it.
Looking at the interface up close, you can see that there is an editor, a list of fields, and a
bunch of formatting options. You can tweak and change it in any way that you’d like, and
even insert data from text files and other places like the registry.
Once you’ve tweaked and created your configuration (more on that below), you can just
save it out to a configuration file to load again any time you need it. Next you’ll need to
make sure that BGInfo updates the information on a somewhat regular basis.
Running BGInfo at Startup
The simplest thing to do is create a shortcut to BGInfo and place it into your startup folder,
and modify that shortcut to include the path to the configuration that you’ve created and
saved using the editor. You’ll also need to add a couple of command-line switches to make it
happen.
The important switches for our purposes are the /TIMER:0 switch, which sets the timeout
before it applies to zero, the /SILENT switch which keeps everything quiet, and the
/NOLICPROMPT switch, which skips the EULA dialog.
Note: the /POPUP switch and the /TASKBAR switch will stick BGInfo into your system tray
and pop up a dialog with system information whenever you click on it, which is definitely a
very useful option.
For example, if we save BGInfo.exe into the C:\Users\Lowell\bin\ folder and put the
configuration as config.bgi into the same folder, we’d use this as the command line:
bginfo.exe c:\users\lowell\bin\config.bgi /timer:0 /nolicprompt /silent
To make it run every time we startup the computer, open up Windows Explorer and
type shell:startup into the location bar to open up the Startup folder.
Then type out the full path to BGInfo followed by the path to the configuration file, followed
by the three switches we mentioned earlier.
At this point you should have a shortcut in your Startup folder that should immediately
display the configuration on the desktop.
You could also open up Task Scheduler and create a new task that runs every x minutes if
you want the information updated more often, but that’s a little beyond the scope of this
lesson.
Tweaking the Displayed Information
Changing the data that is displayed on the screen is easy enough, as the editor panel is just
like any other rich text editor. You can add fields from the pane on the right, tweak the
display of the data, etc. For instance, I wanted to just have a line across the top right-hand
side of my monitor with some useful system information, and then show the name of the
system below it in larger text, so I simply edited, used the align right button, and changed
the font size for the element I wanted to change.
After clicking Apply, this is what displayed in the top right-hand corner of my monitor —
handy stuff for a system administrator.
The Background dialog lets you change the wallpaper behind the image if necessary. For
best results, you’d want to use the “Copy user’s wallpaper settings” the first time, and then
change to the “Use these settings” to specifically select one if necessary.
Note: One little problem is that if you create a new configuration, BGInfo gets a little
confused and resets your wallpaper to black, so you have to set the wallpaper again, and
then apply the configuration.
You can use the Position button to change where on the screen the data will show up, and
tweak a few other variables if necessary.
Clicking the Custom button underneath the Fields box will let you create user-defined fields
that display special data that isn’t normally available, including pulling data from the
registry, environment variables, WMI, files, or even VB Script. By extending BGInfo this way,
you can make it display absolutely anything that you’d like to see on the desktop.
For example, if you want to grab the build number of Windows to use as a data point on the
desktop, you would click the Registry value and then paste in the full path to a registry key
in the Path field. (If you are running 64-bit Windows you would want to check the 64-bit
registry view box or your lookup will be redirected to the 32-bit compatibility section of the
registry.)
The Identifier would then show up in the Fields list, and you can select it to insert into the
rich text editor.
For WMI you can actually browse through all of the zillions of pieces of data and pick one to
display. This would work the same way as the registry value — you’d give it a name, and
then add that name to the rich text editor from the fields list.
For the text file and VB Script user defined fields, you can pull in either the contents of a text
file, which can come from anywhere, or you can create a VB script that runs on the
command line and outputs data that illustrates anything you’d like.
For instance, to show your public IP address on the desktop, you could create a new script in
Notepad, paste the following, and then save it as publicip.vbs.
Dim o
Set o = CreateObject("MSXML2.XMLHTTP")
o.open "GET", "http://ifconfig.me/ip", False
o.send
echo o.responseText
Once you added this to the list, you would then have access to display the public IP address
by adding “publicip” out of the Fields list. As you can imagine, there is a lot more that you
can do with this, to the point of being nearly unlimited.
RELATED ARTICLE
Use BGInfo to Build a Database of System Information of Your Network Computers

For the truly advanced users, you can also create a database on your network and set
BGInfo to run automatically on the client computers to populate the database. This way you
could immediately know anything about them without having to pay for expensive
management software. Be sure to read the linked article for the entire guide.
Next Lesson
Tomorrow we’re going to delve back into the super geeky world of SysInternals with a
thorough examination of some of the command line tools, so be sure to check back for the
rest of the series.
Lesson 8: Using PsTools to Control Other PCs from the Command Line
In today’s lesson in our Geek School series covering SysInternals, we’re going to show you
how to use the PsTools set of utilities to perform all sorts of administration tasks both
locally, and on remote computers as well.
SCHOOL NAVIGATION
If you’ve ever wanted to connect to another computer and run a command, quickly get
information about processes running and optionally kill them, or even stop a service on
another PC, you can use the PsTools utilities to do all of these things and even more.
Obviously you can use Remote Desktop or a similar service to connect to any Windows
computer and actually see the desktop and do anything that you would do locally, but the
PsTools utilities allow you to do many tasks from the command line — or better yet, from a
script that you can re-use later.
These are the type of utilities that work best in a corporate environment, and mastering
these tools will definitely make you much better at your system administration job, save you
time, and let you do things in a much smarter way. Doing things smarter and faster is a
critical skill for being a great sysadmin.
There are twelve tools in the PsTools set, and while some of them are extremely useful,
others have been superseded with tools built into more recent versions of Windows, and
there are a few others which aren’t useful for most people. We’ll go through all of them so
you understand how they work and why you might want to use each one.
 PsExec – executes processes on a remote computer
 PsFile – shows files that are opened on the remote computer through the network
 PsGetSid – displays the security identifier for a computer or user
 PsInfo – lists information about a system
 PsKill – kills processes by name or ID
 PsList – list information about processes on the command line
 PsLoggedOn – list accounts that are logged on either on the machine or connecting
remotely
 PsLogList – pull the event log on the command line
 PsPasswd – change the password for users
 PsPing – a fairly simple ping utility with some additional features
 PsService – list and make changes to Windows services
 PsShutdown – shut down, log off, or suspend a computer
 PsSuspend – suspend and resume processes (rather than killing them)
It’s worth noting that you can use a tool like PsExec to execute all sorts of command-line
utilities on remote computers… including really useful ones like the Autoruns command line
tool and many more. The possibilities are endless once you’ve embraced the power of
PsTools.
All of these tools can be used on local computers, but they are mostly useful for connecting
to remote computers and performing commands on them.
Connecting to Remote Computers ( Syntax for All Utilities)
All of the utilites can be run on either the local or remote computer, so they all have the
same first argument for computer name if needed. Note that you could use the IP address if
you wanted instead. If you omit this argument, the command will operate on your local
computer.
psinfo \\computername
You can also list multiple computers like psinfo \\computer1, computer2, computer3, or you
could put all of the names into a file and reference that like psinfo @computerlist.txt. The
final syntax is psinfo \\* which operates on all computers in the domain, which probably
isn’t something you’ll use every day.
If you need to connect with alternate credentials because your local computer’s account has
a different username and password than the other computer, you can use the -u and -p
options, though we’d note that you might not want to use -p on the command line with a
password in the command for security reasons. Update: as of the latest release of PsExec, no
tool passes passwords as clear text anymore, so the only worry is if somebody can read your
script files and see the password there.
psinfo \\computername -u “user” -p “Password”
The “user” part of the command would change to “DOMAIN\user” if you are in a domain
environment and need to change from the currently running user.
Note: you will generally need to connect to the remote computers with an administrator
account.
Configuring Remote Administration Access
If you are in a domain environment, which most people that need to use PsTools will be, you
can ignore this section entirely as everything should work just fine. For anybody running
Windows 7, 8, or Vista in a home environment or using a couple of computers in an office
without a domain, you will need to tweak User Account Control on the remote computer to
allow PsTools to properly run.
The problem is described well by Microsoft:
When a user who is a member of the local administrators group on the target remote
computer establishes a remote administrative connection by using the net use *
\\remotecomputer\Share$ command, for example, they will not connect as a full
administrator. The user has no elevation potential on the remote computer, and the user
cannot perform administrative tasks.
To explain it in a different way, when you try to connect to another computer and run
something that requires administrator access, there is no way to trigger the UAC prompt
and accept it from your computer, so it won’t connect as administrator.
And this isn’t a bad thing. You shouldn’t change this setting without fully understanding that
you will be allowing an opening for malware to spread from one computer to another —
assuming that malware has your local username and password, and that password is the
same as the other computer, and the malware is that tricky, which most isn’t. But it still isn’t
something to be taken lightly.
And again, if you are in a domain environment, this problem doesn’t exist and doesn’t need
to be changed. And if you are just testing with a bunch of virtual machines, you don’t have
much to worry about.
To tweak UAC to enable PsTools to run you’ll want to open up the Registry Editor and
navigate to the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Windows\CurrentVersion\Policies\System
Once you are there, create a new 32-bit DWORD on the right-hand side, give it the name
LocalAccountTokenFilterPolicy and the value of 1. You don’t have to restart the computer to
make the setting take effect.
Note: just to clarify, this setting needs to happen on the remote computer that you are
connecting to.
PsExec
PsExec is probably the most powerful tool in the kit, as you can execute any command in
your local command prompt just like executing it on the remote computer. That includes
anything that can be run on the command line — you can change registry values, run scripts
and utilities, or connect from that PC to another one. The output of the commands will be
shown on your local PC, rather than on the remote one.
The syntax is simple:
psexec \\computername <options> apptorun.exe <arguments>
Realistically, though, you would want to also include the username and password on the
command line. For example, to connect to another PC and check the network connections
list, you would use something like this:
psexec \\computername -u User -p Password ipconfig
That command would produce output similar to the following:
If you want to pass the output of a command into another command, or you wanted to
redirect the output into a file, you would normally just do something like command.exe >
output.txt, and the same thing happens with PsExec. So a command like the following will
save the output of netstat -an into a file on your Local computer’s root directory.
psexec \\computername netstat -an > C:\connections.txt
If you want to pass the > or | character across the PsExec connection to the remote
computer, you are going to need to use the ^ character, which is a little-known escape
character in the Windows command shell. That, of course, means that we will actually need
to use the command shell on the remote computer, and not just run the process, so we can
do the redirect or pipe in the first place. So that makes our command like this (changing the
path to the home directory where we have write access).
psexec \\computername cmd /c netstat -an ^> C:\users\geek\connections.txt
This example would place the list of open connections generated by netstat into the home
directory of the user on the remote computer, in a file named connections.txt.
Copying Programs to the Remote PC
You aren’t limited to just the applications on the remote PC when using PsExec, and in fact,
you can run anything that you have locally. For instance, if you wanted to do an Autoruns
command-line scan of the remote system, but you only had autorunsc.exe on your local
computer, you can use the -c switch to copy the application over. PsExec will remove the
tool from the remote system once the command is finished.
This is an important time to mention the -accepteula option of most of the SysInternals
tools, which will make sure that the EULA has been accepted on the computer where the
command has been run. We’ll need to add this onto the autorunsc.exe command or else it
will fail on the remote computer.
psexec \\computername -c autorunsc.exe -accepteula
There are a few other options that specify whether the application is always copied, or if it
should be copied if the local application is a higher version than the remote one. You can
just run psexec from the prompt to see those options.
Note: If a command is only available in the command prompt, you need to add cmd /c
before it. This includes pipes and redirects like | and >.
Interacting with the Logged On User on the Remote PC
You can use the -i switch to make the application launch and allow the remote user to
actually interact with the application. You would probably want to combine this with the -d
switch, which doesn’t wait for the remote process to end before PsExec returns control to
you. For instance, this command would open a Notepad window on a remote computer:
psexec \\computername -d -i notepad
You can also choose to run as the SYSTEM user with the -s option, which can be very
dangerous. For example, if you wanted to open the Registry Editor on your own computer,
but with SYSTEM user-level permissions, you could run this command.
psexec -i -d -s regedit.exe
In case you are wondering, yes, this will give you access to a lot of things that you normally
wouldn’t have access to edit in the registry. And yes, it’s a really bad idea.
Running a Full Command Prompt through PsExec
Yes, we just showed you all of those examples of how to run a single command through
PsExec… and it turns out that you can run a full shell on your local computer that is actually
running on the remote computer. It’s just like you were on the console of that server (for
the most part). And luckily, the syntax for this one is really easy (add the username if you
need to).
psexec \\computername cmd.exe
Once you’ve done this, you’ll have a command prompt that is now running on the remote
PC.
The command prompt will work almost like normal, except tab completion isn’t going to
operate at all, but that’s just fine with us.
It’s worth noting that if you want to run PowerShell commands remotely on another
computer, you can do that natively with some tweaks to the configuration. Unfortunately
PowerShell doesn’t work very nicely with PsExec unless you use a bunch of weird
workarounds that aren’t worthwhile.
Other Options
The psexec command has a ton of other really useful options that you can use — each of
these would be used in the space right after \\computername and before any of the other
commands. So think psexec \\computername -option <remote command>.
If you just run the psexec command from the prompt without any extra switches, you’ll see
all of them.
PsFile
This command shows files that are currently opened over the network on a local PC or a
remote PC, and it operates similarly to the Windows “net file” command. The syntax is just
like any other command in the kit.
psfile \\computername
Yeah, this one isn’t as fun as the last one.
If you want to close one of the files and disconnect the person from the resource, you can
close the connection by using the -c option, though that might result in a loss of data since
the file wasn’t closed properly.
psfile \\computername <path> -c
PsGetSid
This displays the security identifier for a computer or user, and takes the standard
arguments. This utility is probably only useful in very particular scenarios, of which we
haven’t personally encountered any. So try it once and forget about it until you need to use
it someday.
PsInfo
This command lists lots of useful information about a system, including the uptime, which is
lots of fun. You can run this one locally to test it out by simply typing psinfo at the command
prompt, assuming your SysInternals tools are in the path.
If you want to get a lot more information out of PsInfo, and I know you do, then you can use
the following switches to add disk information (-d) and hotfixes (-h) and a list of installed
applications and their versions (-s).
psinfo -d -h -s
This results in a lot more information, even on a nearly blank virtual machine:
You can also run PsInfo remotely by adding the computer name and possibly the username
switches… but there is one big problem: it won’t work unless the Remote Registry service is
enabled. Head to the end of the article where we talk about how to enable it on the remote
computer.
PsKill
This command is really simple — it kills processes, by either name or ID, and you can use the
-t switch to optionally kill the entire process tree.
pskill \\computername <PID or Name>
The problem with PsKill is that the latest versions of Windows have a very powerful task
killing utility built right in called Taskkill that has a lot more features.
PsList
This utility is extremely simple, but fairly handy for quickly looking at a computer and seeing
if something is using too much CPU or memory. You can specify the name or part of the
name on the command line to narrow down the list to just a problem application, and you
can see almost all information including threads.
Note: To make this utility work on a remote computer, you’ll need to have the remote
registry service enabled. Make sure to read to the end of the lesson, as we explain how to
deal with that later on.
PsLoggedOn
This utility lists accounts that are logged on either on the machine or connecting remotely.
It’s pretty simple, and largely useful in a system administrator type of environment.
PsLogList
This utility displays a local or remote event log on the command line, and there are a
number of options that can be used for filtering the data.
psloglist \\computer System
There are also the -h, -d, and -m options, which let you narrow down the list of events to
just the last x hours, days, or minutes. The -n option displays the list x records, while the -r
switch reverses the order so the latest records will be at the bottom of the output. The last
option, which we set to “System” in this example, is not actually necessary — if you omit it,
the System log will always be pulled, but you could change it to Application or Security to
pull those logs instead.
It’s worth noting that if you have administrator access to the other computer, you can
simply open Event Viewer and choose Connect from the Action menu. Enter the computer
name in the list, change the credentials if you need to, and access the event logs that way.
The only scenario where we can really see PsLogList being really useful is if you wanted to
script out something to perform an action in case of certain messages in the event log.
PsPasswd
This utility allows you to change the passwords for users, both local and remote. The syntax
is the same as everything else:
pspasswd \\computer -u User -p Password <AccountToChange> <NewPassword>
The benefit to this utility over just using NET USER from the regular command prompt is that
you can change passwords for multiple computers at once, and it works in a domain
environment as well.
PsPing
This utility pings, checks ports, and does latency and bandwidth testing. Pretty simple.
psping <servername>
Or you can check connectivity to a port by adding the port number like this:
psping <servername>:80
There are a ton of advanced options to this command that you will probably want to check
out should you ned to do some network troubleshooting.
PsService
This utility allows you to deal with Windows Services from the command prompt. It’s really
quite easy to use — the syntax works like this:
psservice \\computername <command> <arguments>
The list of commands can be found by looking at the help /? options, but there are a few
options that you’ll find yourself using more than the rest.
 query – Queries the status of a service
 config – Queries the configuration
 setconfig – Sets the configuration
 start – Starts a service
 stop – Stops a service
 restart – Stops and then restarts a service
 pause – Pauses a service
 cont – Continues a paused service
 depend – Enumerates the services that depend on the one specified
 find – Searches for an instance of a service on the network
 security – Reports the security permissions assigned to a service
In particular, the start | stop | pause | restart | cont options are really simple and easy to
understand. For instance in the following command you could replace “start” with any of
those other commands.
psservice \\computername start <servicename>
The other options can be used to query more information about a service, or change the
configuration.
Note: the built-in sc.exe utility has a ton of useful features that overlap with this utility. The
main difference is that PsService is a little more user-friendly.
PsShutdown
This utility allows you to shut down, log off, or even put a computer into sleep mode. The
problem is that it isn’t better than the built-in shutdown.exe utility, and was actually
designed for Windows XP, so it’s recommended to use the built-in utility instead in most
cases.
The one option that PsShutdown provides that you can’t get otherwise is the switch (-d) to
put the computer into sleep mode, which can be handy.
psshutdown \\computername -d
You can also use the -h option to put the computer into hibernate mode instead.
PsSuspend
This utility is very similar to PsKill, but it does something that the built-in Taskkill utility just
can’t — you can suspend processes rather than kill them, which can be very handy if you
want to temporarily stop a CPU-intensive process from running while you complete a
sysadmin task.
Suspending a process is extremely easy:
pssuspend \\computer <PID or Name>
And resuming that process is just as easy — all you have to do is add the -r switch.
pssuspend \\computer -r <PID or Name>
When the Utilities Won’t Connect Because of Remote Registry

Some of these utilities, including PsInfo, PsList, PsLogList, and PsLoggedOn require the
remote registry service to be enabled on the remote computer, and it isn’t enabled by
default on modern versions of Windows.
The good news is that this problem is easily fixable, and you don’t have to leave Remote
Registry enabled. Just run this command using PsService to start the service:
psservice \\computername start RemoteRegistry
And then when you are done with whatever you are doing with PsInfo or PsList, you can
stop the service again using this command:
psservice \\computername stop RemoteRegistry
Simple solutions are the best, aren’t they?
Next Lesson
Make sure to join us tomorrow, when we cover file and disk utilities, and some more
interesting things.
Lesson 9: Analyzing and Managing Your Files, Folders, and Drives
We’re almost done with our Geek School series on SysInternals tools, and today we’re going
to talk about all of the utilities that help you deal with files and folders — whether you are
finding hidden data or securely deleting a file.
SCHOOL NAVIGATION
There are quite a few utilities in the toolkit that deal with all sorts of things that are related
to files or folders or finding data that you didn’t know was there, and there are a few that
are a little on the silly side. Either way, we’ll be covering them all.
The most important file-related tools in the kit to get to know are probably the Sigcheck and
Streams utilities, but it would be wise to read through them all carefully.
Streams Finds and Displays Hidden NTFS Streams
Most people don’t know about this feature, but Windows will let you store data inside a
hidden compartment in the file system called alternate data streams. This basically works by
appending a colon and a unique key to the end of a filename when interacting with it.
RELATED ARTICLE
How to Hide Data in a Secret Text File Compartment

For instance, if you wanted to hide some data in a file, you could do something like echo
Secret > filename.txt:hiddenstuff and even if you opened up that text file in Notepad, you
wouldn’t see the “Secret” text that you added, and there would be no other way to know
that it was even there. In fact, you can do nearly anything you want using this
technique. (Make sure to read our article on the subject for the full explanation).
This is also the technique that allows Windows to magically know that files have been
downloaded from the internet, by hiding data inside the Zone.Identifier field. In fact, you
can delete this alternate data stream using the Streams utility.
The syntax is simple — to see the streams, type the following at the prompt:
streams <filename>
You can also use “streams *.exe” or something like that to see all the files with hidden
stream data, if there are any. The quickest way to see something is to head into your
downloads directory and run it there.
To delete one of the streams or many of them, you can use the -d option:
streams -d <FileOrFolder>
You can also use the -s option to go into subdirectories recursively.
SigCheck Analyzes Files That Aren’t Digitally Signed (Like Malware)
This very useful utility analyzes the digital signatures of files on your system and tells you
whether they are valid or missing a certificate. You can also use it to check files against
VirusTotal from the command line, which is convenient, because that’s the real point of this
tool, is to find malware.
The normal and most useful syntax is to add the -u switch, which only reports problems, and
the -e switch, which only checks executable files. So you could run something like this to
check your system32 directory and make sure that all the files there are digitally signed.
Anything else should be examined very closely.
sigcheck -e -u C:\Windows\System32
You can also use the -v option for an additional check against VirusTotal, but you will need
to use the -vt option the first time to accept their terms and conditions.
sigcheck -v -vt <filename>
SDelete Securely Deletes Files

If you are the paranoid type, you’ll be glad to know that you can securely wipe files from the
command line any time you want. Just use the sdelete utility to whack the file with DoD
compliant deletion protocols. (Of course the NSA probably still has a copy of your file). The
syntax is simple:
sdelete <filename>
You can alternatively clean the free space on a drive by using the sdelete -c option, which
will take longer, but is a good option if you forgot to use sdelete to remove the file in the
first place.
Contig Defragments One or Many Individual Files

If you want to defragment just one single file, or a list of files, you can use the Contig utility
to do just that. Sure, you don’t really need to defragment files in modern versions of
Windows that do it automatically. And yeah, if you are using a solid state drive you should
never defragment nor do you need to. But if you absolutely, positively, must defragment a
single file, this is the utility to do it. The syntax is simple:
contig <filename>
If you want to analyze the fragmentation of a file without actually doing anything, you can
use the -a switch as shown below:
It’s worth noting that even if a file is fragmented, if the file is very large and is only broken
into a few large pieces, you will gain essentially nothing from defragmenting and will have
wasted more time bothering with it than you would save.
du Shows Disk Usage
You can always just right-click any file or folder in Windows Explorer and choose Properties,
or use the ALT + ENTER keyboard shortcut to see the size of a file or folder. But what if you
want to see that data from the command prompt? That’s where the du utility comes in, and
it is also a bit more accurate because it doesn’t count symbolic linked files, and it does check
alternate data streams as well.
The -n option only checks a single folder, without recursing into subdirectories, while the -v
option does recurse and also shows each directory as it goes through the list, and the -l (n)
option checks just “n” levels deep. As in, -l 2 would check 2 levels deep.
PendMoves Displays Files Moving on Next Reboot
Have you ever wondered why application installs make you reboot your computer? The
answer is usually that they want to move some files around that can’t be moved around
while Windows is running, so they use a built-in Windows feature that handles moving or
deleting files on reboot.
The only thing you need to do is run the command, and it will output the data. Why is a
copy of Process Explorer scheduled to move into the Windows folder on the next reboot?
Read on.
MoveFiles Moves System Files when You Reboot

This utility uses the built-in Windows feature to schedule a move, delete, or rename of a file
or directory so that it will happen during the next reboot cycle, before Windows is fully
loaded. The syntax is really simple:
movefile <source> <dest>
If you want to delete a file, you can use an empty destination by using quotes, like movefile
<source> “”. As you can see in the screenshot below, we used the Movefile command to
schedule a copy of process explorer to be moved into the Windows directory to illustrate
how it all works.
Junction Creates Symbolic Links

RELATED ARTICLE
The Complete Guide to Creating Symbolic Links (aka Symlinks) on Windows
Windows supports symbolic links for files and folders, so that you can have more than one
path point to the same file to save space instead of having multiple copies of a file. The idea
is similar to shortcuts, except this is on the file system level and built into NTFS.
The Junction utility allows you to create and delete these links easily. You can also delete
them using junction -d <ShortcutName>.
junction <ShortcutName> <ActualFolder>
The reality, however, is that Windows since Vista has had the ability to create symlinks with
the mklink command, and you may as well use that one instead.
FindLinks Finds Hard Links to Files
This little utility finds all hard links pointing to a file. Hard links are different from symbolic
links in that deleting one hard link does not actually delete the file if there are more hard
links to that file, it just appears to delete it until you have deleted all the hard links. Once
you delete the final hard link, the file will be deleted.
Note: this could actually be an interesting way to make sure that a particular file isn’t really
deleted by somebody that has the habit of deleting files. Just create a hard link to all the
files that you don’t want them to lose.
In any case, you can use this command easily enough:
findlinks <filename>
The only problem is that Windows 7 and 8 have a built-in command that does the same
thing. Use this one instead:
fsutil hardlink list <filename>
Note: It’s always better to learn to use the built-in stuff when possible, because you never
know when you’ll need to do something on somebody else’s computer when you don’t have
your toolkit.
DiskView Displays Disk Structure
This utility allows you to see the structure of your hard drive in great detail, and you can
even zoom all the way in and pick a file to highlight in the list, so you can see where a
particular file is on the drive, and also see whether it is fragmented or not. It’s not terribly
useful for most people, but hopefully you’ve got a scenario where you might need to use it.
Disk2vhd Turns PCs into Virtual Hard Drives
This utility creates a clone of your computer’s hard drive while it is running, and bundles it
all up into a Virtual Hard Drive file that can be used in a virtual machine. And it does this
while the PC is running.
That’s right, you can create a virtual machine of your hard drive while your computer is
running. This could also be really helpful for scenarios where you want to do some forensic
analysis of a machine but on your own computer — you could just create a clone and then
boot it as a virtual machine instead.
The option for Vhdx tells Disk2vhd to use the newer VHDX file format instead of the VHD file
format, which had a number of limitations. By default Disk2vhd is going to create separate
files for each physical drive, but put partitions into the same file. If you simply plan to attach
this VHD file to another virtual machine, or even just mount it on a regular Windows
computer, you can uncheck partitions that you don’t need in the list. If you plan to make a
virtual machine out of it, you should probably leave everything checked.
The VHD output file can actually be placed onto the same drive that you are making a copy
of, but we’d recommend using a second drive if possible just to make it all go faster.
PageDefrag is Obsolete
This utility allowed you to defragment system files during boot, but since it doesn’t work on
recent versions of Windows, you should skip it.
Sync Writes Cached Data to Your Disk
This utility simply syncs all cached data out to the disk to make sure all file changes are
written to the drive and not stored in some buffer somewhere. Of course, you should use
the Safely Remove option every time if you want to be sure you won’t lose data when
pulling a flash drive.
Disk Monitor Shows You Real-Time Hard Drive Activity

This utility shows actual hard drive activity happening in real time — sectors, reads, writes,
the length of the data, it’s all there. The only problem is that it isn’t terribly useful for most
people.
What is a little more useful, maybe, is the disk monitoring “Tray Disk Light” that you can
choose from the Options menu. Once you enable that mode, it will move into the system
tray and blink red for writes, green for reads, or stay gray when nothing is happening.
If only the icon matched Windows 8 a little better.

VolumeID Changes the Drive’s Serial Number
Have you ever noticed how every drive has a serial number that looks like 064B-1E81 or
something equally uninteresting? If you want to change that serial number to something
more fun, you can do it by using the VolumeID utility with this syntax:
volumeid XXXX-XXXX
Please note that the syntax requires using hexadecimal characters, so you can’t type in
GEEK-1337 like we did, because it just won’t work.
Next Lesson
Tomorrow we’re going to wrap up the series with a look at some of the little utilities that we
missed, as well as some guidance on using all of the tools together, and when you should
pull out each tool.
How to use Process Monitor for standard log and for bootlog
TECH92496 January 4th, 2016 http://www.symantec.com/docs/TECH92496
Support/ How to use Process Monitor for standard log and for bootlog
Did this article resolve your issue?
No Yes
Print Article
Products
Subscribe to this Article
Manage your Subscriptions
Search Again
Situation
Process Monitor is an advanced monitoring tool for Windows that shows real-time file
system, Registry and process/thread activity. It combines the features of two legacy
Sysinternals utilities, Filemon and Regmon, and adds an extensive list of enhancements
including rich and non-destructive filtering, comprehensive event properties such as session
IDs and user names, reliable process information, full thread stacks with integrated symbol
support for each operation, simultaneous logging to a file, and much more. Its uniquely
powerful features will make Process Monitor a core utility in your system troubleshooting
and malware hunting toolkit.
Symptoms
How to configure PROCMON and how to create a bootlog
Solution
Prepare “Process Monitor” for logging
1. Login using an account with administrative privilege (for example “Administrator”)
2. Create a folder in system drive (default C:\ ) named “monitor”
3. Download the software using the following link:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
4. Extract the archive to the folder C:\monitor created in step 2.
5. Double Click on the file “Procmon.exe”
6. Click on the “Capture” icon to stop the capture process.

7. The Capture icon will now have a red X over it, meaning that the program is no longer
capturing events.
8. Now go in to the “File” menu ( first from left in the program window)
9. Select “Backing Files” (Shortcut CTRL-B) scrolling down on the menu and click with left
mouse button, or if you use a keyboard scroll down with arrows and press enter
10. This will open the “Process Monitor Backing Files” window.
11. Now click on the radial button near “Use file named:” to enable the named field
12. Insert in the name field the desired destination folder (here we will use the folder
"C:\monitor" that we initially extracted the ProcessMonitor.zip to) and target file name e.g.
“C:\monitor\tempfile.pml”
13. Now click on the OK button to confirm
14. This will bring up the confirmation dialog box shown below:
15. Select “OK” button to continue.
16. As soon as “OK” is selected you will be returned to the main window.
17. Close the program.
18. Double Click on the file “Procmon.exe”.
capturing events.
21. Now go in to the “File” menu ( first from left in the program window)
22. Select “Backing Files” (Shortcut CTRL-B) scrolling down on the menu and click with left
mouse button, or if you use a keyboard scroll down with arrows and press enter
23. Now appears a new windows with title “Process Monitor Backing Files”
24. Verify that ProcMon is using the previously configured named file.
25. Select the “Cancel” button to close the window.

26. Now the program is ready for analysis.
Use “Process Monitor” for “Boot Logging”

1. Login using an account with administrative privilege (Administrator is recommended)
2. Navigate to the folder that ProcessMonitor.zip was extracted to (e.g. C:\monitor)

capturing events.
6. Now go in to the “Options” menu and select “Enable Boot Logging”
7. The following dialog box will open.

8. “Process monitor” is configured to log activity during the next boot. Select the “OK”
button to close the program.
9. Reboot the system

10. Login with the previously chosen account (e.g. Administrator)
11. Allow the system to fully load windows and any associated startup programs. ( Generally
this will take from 5-15 minutes)
12. Navigate to the folder that contains Procmon.exe (e.g. C:\monitor)
14. This will open the following dialog box.
15. Click “Yes” to save the collected data.
16. This will open the Save As dialog box.

17. Insert in the “File name” field the desired name for the output (e.g. bootlog001.pml) and
select the "Save" button.
18. As soon as you select the "Save" button a progress bar appears reporting boot-time
event conversion.
19. Following the boot-time event data conversion, the process will apply the Event Filter.
20. Following the Event Filter application, ProcMon will return to the default console. Note
that the capture icon shows as disabled.
21. The previously defined folder will now contain the following file
“C:\monitor\bootlog001.pml”
References
Site: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Download: http://download.sysinternals.com/Files/ProcessMonitor.zip
Technical Information
By default, Procmon will not collect certain Auto-Protect events. For instructions on how to
do so, please see Document ID TECH98079, "How to Configure Sysinternals' Process Monitor
to Record Symantec's Auto-Protect Events" (link - )
The Case of the Veeerrry Slow Logons

★★★★★
★★★★
★★★
★★
★
Mark RussinovichJuly 1, 201220

 0
 0
This case is my favorite kind of case, one where I use my own tools to solve a problem
affecting me personally. The problem at the root of it is also one you might run into,
especially if you travel, and demonstrates the use of some Process Monitor features that
many people aren’t aware of, making it an ideal troubleshooting example to document and
share.
The story unfolds the week before last when I made a trip to Orlando to speak at Microsoft’s
TechEd North America conference. While I was there I began to experience five minute
black-screen delays when I logged on to my laptop’s Windows 7 installation:
I’d typically chalk up an isolated delay like this to networking issues, common at conferences
and with hotel WiFi, but I hit the issue consistently switching between the laptop’s Windows
8 installation, where I was doing testing and presentations, and the Windows 7 installation,
where I have my development tools. Being locked out of your computer for that long is
annoying to say the least.
The first time I ran into the black screen I forcibly rebooted the system after a couple of
minutes because I thought it had hung, but when the delay happened a second time I was
forced to wait it out and face the disappointing reality that my system was sick. When I
logged off and back on again without a reboot in between, though, I didn’t hit the delay. It
only occurred when logging on after a reboot, which I was doing as I switched between
Windows 7 and Windows 8. What made the situation especially frustrating was that
whenever I rebooted I was always in a hurry to get ready for my next presentation, so had
to suffer with the inconvenience for several days before I finally had the opportunity to
investigate.
Once I had a few spare moments, I launched Sysinternals Autoruns, an advanced auto-start
management utility, to disable any auto-starting images that were located on network
shares. I knew from previous executions of Autoruns on the laptop that Microsoft IT
configures several scheduled tasks to execute batch files that reside on corporate network
shares, so suspected that timeouts trying to launch them were to blame:
I logged off and logged back on with fingers crossed, but the delay was still there. Next, I
tried logging into a local account to see if this was a machine-wide problem or one affecting
just my profile. No delay. That was a positive sign since it meant that whatever the issue
was, it would probably be relatively easy to fix once identified.
My goal now was to determine what was holding up the switch to the desktop. I had to
somehow get visibility into what was going on during a logon immediately following a boot.
The way that immediately jumped to mind as the easiest was to use Sysinternals Process
Monitor to capture a trace of the boot process. Process Monitor, a tool that monitors
system-wide file system, registry, process, DLL and network operations, has the ability to
capture activity from very early in the boot, stopping its capture only when the system shuts
down or you run the Process Monitor user interface. I selected the boot logging entry from
the Options and opened the boot logging dialog:
The dialog lets you direct Process Monitor to collect profiling events while it’s monitoring
the boot, which are periodic samples of thread stacks. I enabled one-second profiling,
hoping that even if I didn’t spot operations that explained the delay, that I could get a clue
from the stacks of the threads that were active just before or during the delay.
After I rebooted, I logged on, waited for five minutes looking at a black screen, then finally
got to my desktop, where I ran Process Monitor again and saved the boot log. Instead of
scanning the several million events that had been captured, which would have been like
looking for a needle in a haystack, I used this Process Monitor filter to look for operations
that took more than one second, and hence might have caused the slow down:
Unfortunately, the filter cleared the display, dashing my hopes for quickly finding a clue.
Wondering if perhaps the sequence of processes starting during the logon might reveal
something, I opened the Process Tree dialog from the Tools menu. The dialog shows the
parent-child relationships of all the processes active during a capture, which in the case of a
boot trace means all the processes that executed during the boot and logon process.
Focusing my attention on Winlogon.exe, the interactive logon manager, I noticed that a
process named Atbroker.exe launched around the time I entered my credentials, and then
Userinit.exe executed at the time my desktop finally appeared:
The key to the solving the mystery lay in the long pause in between. I knew that Logonui.exe
simply displays the logon user interface and that Atbroker.exe is just a helper for
transitioning from the logon user interface to a user session, which ruled them out, at least
initially. The black screen disappeared when Userinit.exe had started, so Userinit’s parent
process, Winlogon.exe, was the remaining suspect. I set a filter to include just events from
Winlogon.exe and added the Relative Time column to easily see when events occurred
relative to the start of the boot. When I looked at the resulting items I could easily see the
delay was actually about six minutes, but there was no activity in that time period to point
me at a cause:
Profiling events are excluded by default, so I clicked on the profile event filter button in the
toolbar to include them, hoping that they might offer some insight:
In order to minimize log file sizes, Process Monitor’s profiling only captures a thread’s stack
if the thread has executed since the last time it was sampled. I therefore was expecting to
have to look at the thread profile events at the start of the event, but my eye was drawn to
a pattern of the same four threads sampled every second throughout the entire black-
screen period:
I was fairly certain that whatever thread was holding things up had executed some function
at the beginning of the interval and was dormant throughout, so was skeptical that any of
these active threads were related to the issue, but it was worth spending a few seconds to
look at them. I opened the event properties dialog for one of the samples by double-clicking
on it and switched to its Stack page, on the off chance that the names of the functions on
the stack had an answer.
When I first run Process Monitor on a system I configure it to pull symbols for Windows
images from the Microsoft public symbol server using the Debugging Tools for
Windows debug engine DLL, so I can see descriptive function names in the stack frames of
Windows executables, rather than just file offsets:
The first thread’s stack identified the thread as a core Winlogon “state machine” thread
waiting for some unknown notification, yielding no clues:
The next thread’s stack was just as unenlightening, showing the thread to be a generic
worker thread:
The stack of the third thread was much more interesting. It was many frames deep,
including calls into functions of the Multiple UNC Provider (MUP) and Distributed File
System Client (DFSC) drivers, both related to accessing file servers:
I scrolled down to see the frames higher on the stack and the name of one of the
functions, WLGeneric_ActivationAndNotifyStartShell_Execute, pretty much confirmed the
thread to be the one responsible for the problem, since it implied that it was supposed to
start the desktop shell:
The next frame’s function, WNetRestoreAllConnectionsW, combined with the deeper calls
into file server functions, led me to conclude that Winlogon was trying to restore file server
drive letter mappings before proceeding to launch my shell and give me access to the
desktop. I quickly opened Explorer, recalling that I had two drives mapped to network
shares hosted on computers inside the Microsoft network, one to my development system
and another to the internal Sysinternals share where I publish pre-release versions of the
tools. While at the conference I was not on the intranet, so Winlogon was unable to
reconnect them during the logon and was eventually – after many minutes – giving up:
Confident I’d solved the mystery, I right-clicked on each share and disconnected it. I
rebooted the laptop to verify my fix (workaround to be precise), and to my immense
satisfaction, the logon proceeded to the desktop within a few seconds. The case was closed!
As for why the delays were unusually long, I haven’t had the time – or need – to investigate
further. The point of this story isn’t to highlight this particular issue, but illustrate the use of
the Sysinternals tools and troubleshooting techniques to solve problems.
TechEd Europe, which took place in Amsterdam last week, gave me another chance to
reprise the talks I’d given at TechEd US. I delivered the same Case of the Unexplained
troubleshooting session I had at TechEd US, but this time I had the pleasure of sharing this
very fresh and personal case. You can watch it and my other TechEd sessions either by going
to my webcasts page, which lists all of my major sessions posted online, or follow these links
directly:
Information on troubleshooting using windows sysinternals.

https://malwaretips.com/threads/using-sysinternals-process-monitor-to-troubleshoot-
problems-in-windows.45250/
Downloading and Installing WinDBG
https://www.sevenforums.com/tutorials/355137-windbg-install-configure-bsod-
analysis.html
1. Download the WinDBG sdksetup.exe setup file.

2. Run sdksetup.exe, and specify the installation location (this example uses the default
location):
3. Once you have accepted the licence agreement, you will be prompted to select the
features to install. Select only the Debugging Tools for Windows option, as shown. Proceed
with installation.
4. The debugging tools will be downloaded and installed.
Step 2
Associate .dmp files with WinDBG
If configured correctly, Windows will write information to a .dmp file when the host system
BSOD's. In order to read the information within the .dmp file, it needs to be associated with
WinDBG.
Open an elevated cmd window. Copy the highlighted text below, and paste it into the cmd
window and hit enter to change directory to the installation location path.
cd\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\
or
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
Now copy this highlighted text, paste it into the cmd window, and hit enter to make the
association.
windbg.exe -IA
This is how it looks when executed in the cmd window.
If done correctly, a new blank instance of WinDBG will open with a confirmation box.
WinDBG can now be closed.
Step 3
Configuring the WinDBG Symbol Path
The symbol path is the location in which WinDBG searches for symbols each time it reads a
binary in the BSOD .dmp file. It is critical to get this step correct.
You can specify any location to create a cache/store of downloaded symbols, but I
recommend using the default location (as used in this tutorial).
To create and set a symbol path, do the following.
1. Start a blank instance of WinDBG by going to:
Start > All Programs > Windows Kits > Debugging Tools for x64 > WinDBG (x64)
2. In the WinDBG panel, go to:
File > Symbol File Path
3. Copy the highlighted text below and paste it into the Symbol Search Path box, and click
OK - there is no confirmation.
SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
What that line means is :
 Create a folder called C:\SymCache

 Download new symbols from the msdl site and save them to C:\SymCache
4. Save the symbol path by going to:
File > Save WorkSpace
5. Close WinDBG.
Step 4
Testing the WinDBG Installation
1. Download this small zip file.
test.zip
2. Open it, and double click the .dmp file.
3 WinDBG should open automatically and you should see some text appearing in the
workspace. Since this is the first .dmp file being read on your system, WinDBG appears to be
- slow do not interrupt it. What is happening is:
 A folder called Symcache is being created on C:
 Symbols are being downloaded and saved to C:\Symcache
The next time a .dmp is opened, it will be quicker since it already has some symbols. Over
time the C:\Symcache folder will grow in size as more symbols are added. My current
Symcache folder is 1.07GB in size.
Tip
If you think your \Symbols folder is starting to take up too much disk space, simply delete
the contents of the folder in Windows Explorer - WinDBG will automatically download the
required symbols when you open a .dmp again.
You will know the reading of the .dmp file is complete when our output looks like this. Note
the breakpoint that I have highlighted in bold text red - that means the .dmp file has been
completely read.
Code:
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Symbol search path is:
SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18247.amd64fre.win7sp1_gdr.130828-1532
Machine Name:
Kernel base = 0xfffff800`02a53000 PsLoadedModuleList = 0xfffff800`02c966d0
Debug session time: Fri May 2 11:37:27.580 2014 (UTC + 9:30)
System Uptime: 0 days 0:04:04.718
Loading Kernel Symbols
.
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads
that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
..............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.....
***************************************************************************
****
* *
* Bugcheck Analysis *
* *
***************************************************************************
****
Use !analyze -v to get detailed debugging information.
BugCheck 24, {1904fb, fffff88008f94c48, fffff88008f944a0, fffff80002ddde2e}
Probably caused by : ntkrnlmp.exe ( nt!FsRtlNotifyFilterReportChange+122 )
Followup: MachineOwner
---------
To close WinDBG go to File > Exit
You are done. WinDBG has been installed, .dmp file associations created, and symbol
path correctly setup.
Tip
If you open the .dmp files from within the .zip file, you never need to save
individually .dmp files to your HDD/SSD - all you need to do is delete the original .zip file
once you are finished with that BSOD. This will save you a lot of space in the long run.
The Windows 7 Boot Process (sbsl)
https://social.technet.microsoft.com/wiki/contents/articles/11341.the-windows-7-boot-
process-sbsl.aspx
Written by Claus Witjes and Arne Stremlau
This article about the Windows boot process is part of a continuing series on OS boot and
user logon delays on Windows computers joined to Active Directory domains. Related
articles describing known issues and tools to troubleshoot slow boots and user logons can
be found in the following links:
 Root Causes for Slow Boots and Logons (sbsl)
 Tools for Troubleshooting Slow Boots and Slow Logons (sbsl)
 Troubleshooting Slow Operating System Boot Times and Slow User Logons (sbsl)
A question that Premier Field Engineers often get asked onsite is “Why do our users wait so
long for Windows to boot that they sometimes have time to get a cup of coffee?”
The reality is that there are a myriad of reasons including hardware performance, network
performance, the amount of the workloads added by administrators as well as inefficiencies
in Microsoft and ISV applications and OS components.
The goal of this article is to give readers an overview of the Windows boot process so that
you can better troubleshoot a slow OS start or slow user logon that is caused by delays in
the OS boot process. Related problems about resuming from sleep, wake from hibernate, or
OS shutdown processes are not covered in this article.
Table of Contents
 Boot Process Overview
 BIOS Initialization
 OS Loader
 OS Initialization
o Sub phase 1 - PreSMSS: Kernel Initialization
o Sub phase 2 - SMSSInit : Session Initialization
o Sub phase 3 - WinLogonInit: Winlogon Initialization
o Sub phase 4 – ExplorerInit: Explorer Initialization
 The PostBoot phase
 The ReadyBootPrefetcher
 Additional references
Boot Process Overview

Fast OS startup performance is critical for a good user experience. The time required to boot
the operating system on a given computer to the point where the user can start working is
one of the most important benchmarks for Windows client performance. The Windows boot
process consists of several phases which are explained in more detail by the picture and
supporting text below.
The Windows Performance Toolkit (included in the Windows 7.1 SDK ) allows you to
investigate most of the boot phases (except for BIOS Initialization and OS Loader).
BIOS Initialization
During the BIOS Initialization phase, the platform firmware identifies and initializes
hardware devices, and then runs a power-on self-test (POST). The POST process ends when
the BIOS detects a valid system disk, reads the master boot record (MBR), and starts
Bootmgr.exe. Bootmgr.exe finds and starts Winload.exe on the Windows boot partition,
which begins the OSLoader phase [1].
The BIOS version, the BIOS configuration and the firmware of the computer hardware
components can have an impact on the overall boot performance. There is no way to trace
this phase using the Windows Performance Toolkit. You need to manually measure the
time. In order to optimize or troubleshoot this early phase in the overall computer startup
process, make sure to update the BIOS version and firmware of all hardware components to
the latest versions. In addition check the BIOS configuration (device boot order, PXE boot-
enabled, Quick/Fast boot (POST check) enabled, AHCI settings, and so on).
Be careful changing the BIOS configuration or updating the firmware/UEFI/BIOS versions.
Read the hardware vendor manuals carefully because misconfigurations and failed updates
can cause complete system outages. Create a backup of your system and data beforehand.
OS Loader
During the OSLoader phase, the Windows loader binary (Winload.exe) loads essential
system drivers that are required to read minimal data from the disk and initializes the
system to the point where the Windows kernel can begin execution. When the kernel starts
to run, the OSloader loads the system registry hive and additional drivers that are marked as
BOOT_START into memory. [1]
This phase is mainly impacted by boot start drivers. While a delay caused by a dual boot
menu would be easy to fix, make sure that all boot start drivers are signed and up-to-date.
To identify boot start drivers which are not signed:
1. Create a boot trace using the Windows Performance Toolkit. For more information
about how to create a trace, see slow boot and logon analysis articles for analysis.
2. Run xperf –i <boottrace.etl> -o bootevents.txt –a dumper
3. Findstr /C:”I-DCStart” bootevents.txt > bootevents.csv
4. Open the bootevents.csv using Excel and run signtool verify /v <driver>
Signtool.exe is part of the Windows SDK .
5. If you find a driver which is not signed, look for driver updates.
OS Initialization
During the OS Initialization phase, most of the operating system work occurs. This phase
involves kernel initialization, Plug and Play activity, service start, logon, and Explorer
(desktop) initialization. The OS Initialization can be divided into four subphases. Each
subphase has unique characteristics and performance vulnerabilities. [1]
After you have taken a boot trace the different subphases are shown as follows in
XPERFVIEW.EXE:
Sub phase 1 - PreSMSS: Kernel Initialization
The PreSMSS subphase begins when the kernel is invoked. During this subphase, the kernel
initializes data structures and components. It also starts the PnP manager, which initializes
the BOOT_START drivers that were loaded during the OSLoader phase. [1]
Sub phase 2 - SMSSInit : Session Initialization
The SMSSInit subphase begins when the kernel passes control to the session manager
process (Smss.exe). During this subphase, the system initializes the registry, loads and starts
the devices and drivers that are not marked BOOT_START, and starts the subsystem
processes. SMSSInit ends when control is passed to Winlogon.exe. [1]
Sub phase 3 - WinLogonInit: Winlogon Initialization
The WinLogonInit subphase begins when SMSSInit completes and starts Winlogon.exe.
During WinLogonInit, the user logon screen appears, the service control manager starts
services, and Group Policy scripts run. WinLogonInit ends when the Explorer process starts.
[1]
Sub phase 4 – ExplorerInit: Explorer Initialization
The ExplorerInit subphase begins when Explorer.exe starts. During ExplorerInit, the system
creates the desktop window manager (DWM) process, which initializes the desktop and
displays it for the first time. [1]
A detailed analysis of each phase would go far beyond the scope of this article. The analysis
always starts with a boot analysis trace created with the Windows Performance Toolkit,
which is described in the Windows On/Off Transition Performance Analysis
Whitepaper . Common performance vulnerabilities are described in the whitepaper as

well.
Still, it might require more tools (like parallel network traces and additional debug logs such
as Gpsvc logging) to fully analyze a problem.
For now, begin your analysis on phases that consume the most time and compare traces
with a fresh/clean-OS installation on same hardware.
To give you two examples:
If the WinLogonInit phase takes a long time, you can use the Winlogon graph for further
analysis.
In this example the Group Policy processing took around 160 seconds to complete, before
the Windows desktop could be loaded. While the Winlogon graph does not explain why it
took 160 seconds to complete GPO processing (which could be related to network issues,
policy settings, GPO preferences, scripts, and so on), your can see where to investigate
further.
In another example while analyzing the ReadyingProcess/ReadyingThreadId graphs we
found the profile service waiting about 25 seconds on the network.
The PostBoot phase

The PostBoot phase includes all background activity that occurs after the desktop is ready.
The user can interact with the desktop, but the system might still be starting services, tray
icons, and application code in the background, potentially having an impact on how the user
perceives system responsiveness. [1]
The ReadyBootPrefetcher
During the Windows boot process a lot of data is read from disk and I/O pressure is one of
the determining factors for boot performance. The Windows prefetcher (or ReadyBoot)
helps to read data into memory before Windows needs it. In addition each reboot will allow
the prefetcher to better predict what data is needed.
While ReadyBoot is usually turned on for classic harddisks, it is off for fast SSDs, of
if WinSAT disk score is > 6.0.
One way to analyze the prefetcher activities is to run xperf.exe from the Windows
Performance Toolkit.
Xperf –i <boottrace.etl> - o prefetcher.txt –a bootprefetch – summary
To “train” a system, you can run the xbootmgr.exe with the –prepsystem command option.
The above should give you some insight into where to start looking for issues during the
Windows boot phase, as it will help you identify the correction section to start
troubleshooting.
A recommendation is to check the hardware platform thoroughly by updating the BIOS and
checking hard drive performance with benchmarking tools prior to searching for the
problem on the OS layer.
Additional references
1. Windows On/Off Transition Performance Analysis, http://msdn.microsoft.com/en-
us/windows/hardware/gg463386.aspx
2. Windows On/Off Transitions Solutions Guide, http://msdn.microsoft.com/en-
us/windows/hardware/gg463230.aspx
Wiki content:
https://social.technet.microsoft.com/wiki/contents/articles/tags/Slow+Login/default.aspx
https://social.technet.microsoft.com/wiki/contents/articles/10130.root-causes-for-slow-
boots-and-slow-logons-sbsl.aspx
PROBLEM:
You need to export your Outlook signatures from computerA to computerB
SOLUTION:
On the source computer, open the folder which containins the signature files.
Select Start/Run and then type %APPDATA%\Microsoft\Signatures.
Copy/paste folder content to the same location on the destination computer.
Troubleshooting Windows Startup Problems

There are a few software that can trace the amount of time taken to startup a program in
Windows. It is very useful to determine the process that takes the most time in load.
Process Monitor
Process Monitor is a very powerful tool by Sysinternals that is able to show file and registry
activities in real time. If configured properly, you can actually use it to log boot events and
analyze those events to determine which process takes a long time to start. Simply follow
the steps below:
1. Download Process Monitor , extract and run the Procmon.exe executable file.
2. Click on Options menubar and select Enable Boot Logging.
3. Tick “Generate thread profiling events“, make sure that the every second option is
selected and click OK.
4. Restart your computer and run Process Monitor again when you’ve booted in to
Windows.
5. Click Yes button when you’re asked to save the collected data and save the process
monitor log file. Process Monitor will run after it’s finished converting the boot time event
data and applying event filter.
6. Go to the Options menubar and select “Select Columns“.
7. Select “Duration” and click OK.
8. Go to Filter menubar and select Filter or alternatively you can press Ctrl + L. Set it up
according to the screenshot below. Make sure to click the Add button first followed by OK.
9. You can now check for processes with one of the highest duration and try disabling it
from Windows startup.
As you can see from the screenshot above, one of McAfee’s process takes 36 seconds to
start. You can try disabling the software from startup and if you can’t find it in the program’s
options, you can use third party startup manager tools like Autoruns.
Soluto
Soluto started off as a software that analyzes Windows startup programs, then it got a bit
bloated because it turned into a web application with extra features such as remote control
added to it. Now Soluto is a mobile app to help locate your missing smartphone. If you’re
looking for a more user friendly tool to analyze startup programs that takes a lot of time to
run, Soluto is your best choice.
https://www.raymond.cc/blog/how-to-troubleshoot-windows-startup-logoff-login-and-
shutdown-problems/
http://www.ghacks.net/2009/10/09/use-process-monitor-to-optimize-the-windows-boot-
process/
Use Process Monitor To Optimize The Windows Boot Process
by Martin Brinkmann on October 9, 2009 in Software, Windows - Last Update:November
22, 2009 12
There are not a lot of tools available for the Windows operating system that measure and
optimize the Windows boot process. The mysterious Microsoft Bootvis, which was later
retracted by Microsoft, or Boot Timer, a program that can only measure the boot speed, are
just two programs to measure the boot speed. Many tips exist on how to reduce the boot
speed of the operating system. Some solid, like reducing the number of installed fonts or
programs that run on startup, while others, like clearing the Windows prefetch folder, will
have the opposite effect.
Process Monitor comes with an option to log the Windows boot process. It will log
everything which usually results in boot logs that are larger than 100 Megabytes. The
program can however be used - with some expertise - to locate problematic drivers that
slow down the boot process.
Here is how this is done. Download and start Process Monitor. Select the Options menu at
the top and the Enable Boot Logging option in that menu. This makes Process Monitor log
the next boot process of the operating system.
Restart the computer afterwards and start Process Monitor once the operating system has
loaded. You will be asked to save the boot log to a directory on the hard drive. Load that
boot log afterwards using [Ctrl O] or File > Open. This is a huge log file and the first thing
that needs to be done is to filter for entries that are related to system drivers. You can do
that by pressing [Ctrl L]. This will open the filter menu.
Locate the filter Process Name is System Exclude and remove it from the list of filters. Now
add the following two filters to the list:
Process Name is System Include
Path ends with .sys Include
A click on ok will only display the entries that match both filters that have been added. This
is still a list of 2500+ entries. The important part is to look at the time of day column. This
lists the load time for all operations. All you need to do now is to locate gaps between
events. Gaps of a few seconds need to be analyses, everything else is usually not worth
analysis.
The example above shows a gap of almost 16 seconds between the two marked entries.
Look at the path of the entry that is using that much boot time, the driver name is located at
the end of the path. In this example it was sptd.sys. A quick Google search revealed that it is
a driver used by Daemon Tools. There are two options available once the program has been
identified.
It is possible to research the topic further by visiting forums (see if other users have the
problem, find possible solutions), contacting the developer and updating the program or
hardware (if possible). The other option is to remove the program from the computer
system if it is not needed or if alternatives are available that do not increase the boot time
by that amount.
After installing Soluto, you’d need to restart your computer at least once for it to trace the
background programs load time. Running the Soluto shortcut in the start Menu will open up
your default web browser with your computer listed under My Devices. Click on the
computer and go to Background Apps. You can expand the different categories to view the
time taken to load during bootup. Do note that you can only delay or remove the app from
boot on removable and potentially removable apps category. For required apps, again you
can rely on third party tools like Autoruns.
Download Soluto
Troubleshooting Windows Shutdown Problems
Troubleshooting Windows shutdown problems is more difficult and most of the time a
computer technician would have to go through a series of different tests such as shutting
down from safe mode, shutting down using a Live CD and disabling services to narrow down
the problem. Fortunately Microsoft has provided Windows Performance Analyzer and
Recorder tool from their Software Development Kit (SDK) which can be used to analyze
shutdown problems. Simply follow the steps below:
1. Download Windows SDK by clicking the Install and download hyperlink and run
sdksetup.exe.
2. Select the option “Install the Windows Software Development Kit for Windows 8.1 to this
computer” and click Next.
3. If you’re not comfortable with Microsoft collecting usage data, then select No.
4. Click the Accept button for license agreement.
5. Select only the “Windows Performance Toolkit” checkbox and click Install.
6. After finished installation, run Windows Performance Recorder shortcut from the start
menu.
7. Set the options according to the screenshot below and click the Start button.
Performance scenario: Shutdown
Detail level: Verbose
Logging mode: File
Number of iterations: 1
8. It is optional to type in a detailed description of the problem. Click the Save button to
continue. Then click OK to shutdown your computer.
9. When Windows is restarted, Windows Performance Recorder will automatically start
gathering system shutdown trace information. Once it is done, click the Open in
WPA button.
10. Windows Performance Analyzer will now open and automatically load the event trace
log file generated by Windows Performance Recorder. Double click on System Activity from
the left hand sidebar and a graph will be added to the analysis view.
11. Sort the duration by clicking on the column and look for the process that takes a long
time to terminate during shut down.
Since Windows XP, there is a built-in function to enable verbose startup, shutdown, logon,
and logoff status messages that can help in troubleshooting startup and shutdown
problems. For example, if your computer hangs a long time at “Stopping services” during
shutdown, it is most likely a problem with one of the services that is causing the slow shut
down.
Enabling Verbose Status message requires two new registry entries to be added to:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Right click, go to New, select DWORD, name it as VerboseStatus and set the value to 1.
Create another DWORD with the name DisableStatusMessages and set the value to 0. For
your convenience, simply download the registry file below and run it to enable verbose
status message.
Winsat
ping -t raymond.cc|cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" &&

echo(!date! !time! !data!)&ping -n 2 raymond.cc>nul" >C:\pingtest.txt
Read More: https://www.raymond.cc/blog/timestamp-ping-with-hrping/
Debugger commands.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff563187(v=vs.85).aspx
Windows debugging information:
https://blogs.msdn.microsoft.com/ntdebugging/2008/08/28/basics-of-debugging-windows/
https://www.tenforums.com/tutorials/5558-windbg-basics-debugging-crash-dumps-
windows-10-a.html
Symbols:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Or if you are using different Symbols:
SRV*c:\Vistasymbols*http://msdl.microsoft.com/download/symbols
SRV*c:\XPsymbols*http://msdl.microsoft.com/download/symbols
"srv*c:\cache*http://msdl.microsoft.com/download/symbols;"
.sympath srv*https://msdl.microsoft.com/download/symbols
.sympath srv*c:\MyServerSymbols*https://msdl.microsoft.com/download/symbols
.sympath
c:\MyRegularSymbols;srv*c:\MyServerSymbols*https://msdl.microsoft.com/download
/symbols
Debugging info:
Windows 10: WinDBG - The Basics for Debugging Crash Dumps in Windows 10
Page 1 of 3123 Last
WinDBG - The Basics for Debugging Crash Dumps in Windows 10

Basic WinDBG methods for debugging crash dumps in Windows 10
Published by Gav W
2015-04-23Category: BSOD
WinDBG - The Basics for Debugging Crash Dumps in Windows 10
Information
WinDBG (Windows DeBuGger) is an analytic tool used for analysing and debugging
Windows crash dumps, also known as BSODs (Blue Screens of Death). It is part of
the Windows Developer Kit which is a free download from Microsoft and is used by the vast
majority of debuggers, including here on Ten Forums.
Note
The tutorial below outlines the basic instructions when analysing dump files, it is by no
means a complete and definitive guide. This tutorial will show you how to look for
problematic drivers and highlights a few other common basic issues that arise when
debugging. There are many commands to master within WinDBG and many different
methods to use for different STOP codes which aren't covered in this tutorial.
Mastering WinDBG and becoming proficient in debugging crash dumps take a lot of time
and dedication, it is certainly not a quick process but can be highly rewarding once dumps
start to make more sense.
INTRODUCTION
Table of Contents
Part One: WinDBG Installation and Configuration

Part Two: Opening BSOD Logs
Part Three: The Dump File and Basic Analysis
Part Four: Common Bugchecks and Plans of Attack
Part Five: SCSI Pass-Thru Direct (SPTD)
Part Six: Recommended Research Materials
PART ONE
WinDBG Installation and Configuration
To install and configure WinDBG follow WinDBG - Install Configure - Windows 10

Forums for full instructions.
PART TWO
Opening BSOD Logs
Step One: 7Zip and Opening Dump Files

Step Two: The WinDBG Interface
STEP ONE
7Zip and Opening Dump Files
Information
Dump files are saved with the .dmp file extension and are identified by the icon below.
Small memory dump files (most commonly used for analysing BSODs) are saved locally
to %SystemRoot%\Minidump.
For information on configuring which dump files Windows creates see Dump Files -
Configure Windows 10 to Create on BSOD.
A) When a log file is downloaded from Ten Forums it will be in the form of a .zip file. The
easiest way to access the contents is using 7Zip, a free open source file compression tool.
Once 7Zip is installed download an uploaded log file from a thread in BSOD Crashes and
Debugging - Windows 10 Forums and open the saved destination folder. Logs can appear
as ZIP Files or WinRAR Archives (see image below).
EXAMPLE:
B) Right click on the log you wish to examine, hover over 7Zip in the context menu and
click/tap on Open archive
C) Once the archive is opened you'll see the dump files located at the top of the archive. The
number of dump files present will vary from archive to archive and is completely dependent
on how many BSODs the user has received.
Tip
Always open dumps from the most recent date backwards, opening older dumps first can
give you a false picture of what the current issue actually is. Note the date of the dump files
too, dumps that are many months old may no longer be relevant.
D) On occasion you will encounter an archive that contains no dump files. This usually
means that the user's Windows configuration is not set to create dump files on BSOD, refer
the user to Dump Files - Configure Windows 10 to Create on BSOD to ensure the machine
creates dump files on subsequent BSODs. The user will have to upload new logs once new
BSODs have been encountered to capture the new dump files.
EXAMPLE:
E) Double click/tap on the most recent dump which will open in WinDBG provided it has
been configured correctly.
STEP TWO
The WinDBG Interface
When you open your first dump file you will be greeted with a window like the one below.
It's worth noting that the dump readout window (highlighted in the screenshot above) is
separate to the WinDBG window. It can be moved around and/or resized (by dragging the
corner of the window) within the WinDBG window. Manipulate the dump readout window
to the size that suits your personal preference, giving yourself a bigger workspace can make
for easier reading.
EXAMPLE: Dump window manually resized for larger viewing area:

The dump file will take a few seconds to load as it connects to the internet and downloads
the required symbols to display in the readout. You will see the message Debugee not
connected in the command bar while the symbols are downloaded. You can not work on
the dump file until all of the relevant symbols are downloaded.
Once the symbols have been downloaded and the dump is ready to analyse you will see the
message Followup: MachineOwner at the bottom of the dump text.
At this point you're ready to start analysing the dump file. All commands are entered into
the command bar at the bottom of the dump window.
PART THREE
The Dump File and Basic Analysis
Step One: Bugchecks At a Glance

Step Two: !thread and Driver Analysis
Step Three: !analyze-v and !irp
STEP ONE
Bugchecks At a Glance
Bugchecks are always presented in the form of a STOP followed by a hexadecimal number,
the hexadecimal value always being 0xXXXXXXXX. The hexadecimal code defines the type of
bugcheck. Bugchecks can be referred to in the following ways:
EXAMPLE:
STOP: 0x0000000A
0x0000000A
0xA
A
All of these methods equate to the same bugcheck. For the remainder of this tutorial
bugchecks will be referred to in the shorthand format (0xA).
The first thing you need to note when opening a dump file is the Bugcheck code, this will
largely define the underlying issue that caused the crash. To identify a Bugcheck code refer
to the Windows Dev Center Bug Check Code Reference. In the example below we'll be
dealing with a 0x9F.
Having consulted the Bug Check Code Reference you will learn that a 0x9F is
a DRIVER_POWER_STATE_FAILURE. This is addressed later in this tutorial.
STEP TWO
!thread and Driver Analysis
One common cause of BSODs is third party device drivers. To see if a device driver has been
named in the crash dump you will need to dump the stack, follow the steps below to
perform the procedure and see which drivers, if any, have been named in the stack.
1: In the command bar type in !thread and hit enter, this will display the information from
the active thread at the time of the crash.
2: Scan through the thread until you find the Base and Limit texts and their hexadecimal
outputs.
Code:
Base fffff80000b9b000 Limit fffff80000b95000
In the command bar type dps followed by the Limit value first and the Base value second, it
is important to input the values in the correct order. Hit enter to dump the stack.
Code:
dps fffff80000b95000 fffff80000b9b000
Tip
You cannot right click and copy within the WinDBG window. Select the text required by
highlighting with the mouse and using CTRL+C, then paste the text into the command bar
using CTRL+V.
3: When the stack has been dumped you will see a wall of hexadecimal text, a small
example is outlined in the code below:
Code:
fffff800`00b9a590 fffffa80`0e746d08
fffff800`00b9a598 fffff880`0f00b768 dxgmms1!VidSchiFreeQueuePacket+0xa4
fffff800`00b9a5a0 fffffa80`11854848
fffff800`00b9a5a8 fffffa80`0e7c17a8
fffff800`00b9a5b0 00000000`00000000
fffff800`00b9a5b8 fffffa80`0e746d18
fffff800`00b9a5c0 00000000`00000000
fffff800`00b9a5c8 fffffa80`0e7c17a8
fffff800`00b9a5d0 00000000`00000002
fffff800`00b9a5d8 fffffa80`0e746b10
fffff800`00b9a5e0 fffffa80`0e7c1010
fffff800`00b9a5e8 fffff880`0f00a382
dxgmms1!VidSchiProcessCompletedQueuePacketInternal+0x44e
fffff800`00b9a5f0 fffffa80`11854840
fffff800`00b9a5f8 fffffa80`0e7428b0
fffff800`00b9a600 fffffa80`11854840
fffff800`00b9a608 fffffa80`0e7ca000
fffff800`00b9a610 00000000`00000000
fffff800`00b9a618 fffffa80`11854840
fffff800`00b9a620 00000000`00000000
fffff800`00b9a628 00000000`00000000
fffff800`00b9a630 fffffa80`0e7c1690
fffff800`00b9a638 fffff800`03288dd6 nt!KeSetEvent+0x106
fffff800`00b9a648 00000000`00000000
fffff800`00b9a650 fffffa80`0e7c17a0
fffff800`00b9a658 fffff880`0f00c48b dxgmms1!VidSchiSignalRegisteredEvent+0xe7
fffff800`00b9a660 fffff800`00000001
fffff800`00b9a668 00000000`00000001
fffff800`00b9a670 00000000`00000000
fffff800`00b9a678 fffffa80`0e7428b0
fffff800`00b9a690 00000000`00000000
fffff800`00b9a698 fffffa80`0e746b10
fffff800`00b9a6a0 fffffa80`0e7cb340
fffff800`00b9a6a8 fffff880`0f0097e6 dxgmms1!VidSchiProcessDpcCompletedPacket+0x3b6
fffff800`00b9a6b0 fffffa80`00000000
fffff800`00b9a6b8 fffffa80`00000000
fffff800`00b9a6c0 00000000`00000002
fffff800`00b9a6c8 00000000`00000000
fffff800`00b9a6d0 00000000`00000000
fffff800`00b9a6d8 00000000`00000000
fffff800`00b9a6e0 00000000`0000000a
fffff800`00b9a6e8 fffffa80`0e7cb350
fffff800`00b9a6f0 fffffa80`0e7cb350
fffff800`00b9a6f8 fffff880`0f010127 dxgmms1!VidSchiInterlockedInsertTailList+0x47
fffff800`00b9a700 00000000`00000000
fffff800`00b9a710 fffffa80`0e7cab10
fffff800`00b9a718 00000000`00000000
fffff800`00b9a720 00000000`00000000
fffff800`00b9a728 fffffa80`0e7c17a8
fffff800`00b9a730 fffffa80`0e7cb302
fffff800`00b9a740 fffffa80`0e7cb340
fffff800`00b9a748 fffff880`0f008e34 dxgmms1!VidSchDdiNotifyDpcWorker+0x1c0
fffff800`00b9a750 00000000`00000000
fffff800`00b9a760 00000000`00000000
fffff800`00b9a768 fffffa80`0d285000
fffff800`00b9a770 fffff800`00b94080
fffff800`00b9a778 00000000`00000022
fffff800`00b9a780 00000000`00000000
fffff800`00b9a788 00000000`00000000
fffff800`00b9a790 fffffa80`0e7bb000
fffff800`00b9a798 fffff880`0f008c63 dxgmms1!VidSchDdiNotifyDpc+0x9f
fffff800`00b9a7a0 00000007`00000030
fffff800`00b9a7a8 fffffa80`0d2971f8
fffff800`00b9a7b0 fffffa80`0e7c1010
fffff800`00b9a7b8 fffffa80`0d289000
fffff800`00b9a7c0 00000000`00000000
fffff800`00b9a7c8 fffffa80`0e7c17b8
fffff800`00b9a7d0 00e3e790`00000030
fffff800`00b9a7d8 00000000`0000000c
fffff800`00b9a7e0 00000000`00000000
fffff800`00b9a7e8 fffff880`102dc1cf dxgkrnl!DxgNotifyDpcCB+0x77
fffff800`00b9a7f0 fffffa80`0d74e480
fffff800`00b9a7f8 00000000`00000000
fffff800`00b9a800 fffff800`00b94080
fffff800`00b9a808 00000000`00000022
fffff800`00b9a810 fffff800`00b9a920
4: To see whether a driver or drivers are named in the stack, scroll through and scan for
outputs like the two examples below:
Here you can see two offending drivers, atikmdag.sys and lvuvc64.sys. These drivers have
been named in the crash dump so you can assume they're contributing to the problem. First
you must identify the drivers, to do this refer to the archive opened in Part One C) and open
the drivers.txt file.
Note
If your default program association for .txt files isn't already set to Notepad, change it prior
to opening.
5: In the drivers.txt file, looking in the Path column, scroll down until you find the name of
the driver listed in the dump file. Reference the Display Name and Description columns for
the identity of the driver.
atikmdag.sys:
In this case the Display Name and Description read the same as the driver name, in such an
instance a quick Google search for atikmdag.sys will reveal it's the ATI Graphics driver.
lvuvc64.sys
In this case the driver is named as a LogitechHD Webcam C61 driver.
6: Now you have identified the drivers, check the age of each one by typing lmvm followed
by the driver name (minus the .sys) into the command bar of WinDBG and hit enter.
Code:
lmvm atikmdag
Gives the readout:
Code:
0: kd> lmvm atikmdag
start end module name
fffff880`0f055000 fffff880`102d9000 atikmdag T (no symbols)
Loaded symbol image file: atikmdag.sys
Image path: \SystemRoot\system32\DRIVERS\atikmdag.sys
Image name: atikmdag.sys
Timestamp: Fri Nov 21 02:30:27 2014 (546EA3C3)
CheckSum: 0121F198
ImageSize: 01284000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
The date of the driver is highlighted giving an indication of whether an update to a newer
version or rollback to an earlier version should be applied to test.
Code:
lmvm lvuvc64
Gives the readout:
Code:
0: kd> lmvm lvuvc64
fffff880`05ad5000 fffff880`05f5e300 lvuvc64 T (no symbols)
Loaded symbol image file: lvuvc64.sys
Image path: \SystemRoot\system32\DRIVERS\lvuvc64.sys
Image name: lvuvc64.sys
Timestamp: Fri Sep 21 20:03:12 2012 (505CB9F0)
CheckSum: 0048F35A
ImageSize: 00489300
In this case the date of the driver would indicate an update is required as the installed
version is relatively old.
This method can be applied to all drivers that appear in stacks within dump files. It is worth
noting however that not all dump files will show drivers as the problem, in some instances it
may be hardware that is causing issues but if the STOP code is one that normally indicates a
driver as being the problem it may be necessary to run Driver Verifier to weed out the
offending driver. These calls come with experience, and identifying drivers as causes of
BSODs is just the tip of the proverbial iceberg.
STEP THREE
!analyze-v
The !analyze command displays information about the current exception (or Bugcheck),
adding the -v extension displays the verbose output as pictured below. Two points of
information to take from the !analyze-v output in this instance is Arg4 (the blocked irp) and
the FAILURE_BUCKET_ID and BUCKET_ID (pictured below).
Type !irp into the command box followed by the value of Arg4 and hit enter.
Code:
!irp fffffa800ff17ca0
The output from !irp shows that the third stack is active and blames athrx.sys for
the DRIVER_POWER_STATE_FAILURE.
Code:
>[ 16, 2] 0 0 fffffa800d879050 00000000 00000000-00000000
Unable to load image \SystemRoot\system32\DRIVERS\athrx.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for athrx.sys
*** ERROR: Module load completed but symbols could not be loaded for athrx.sys
\Driver\athr
As alluded to in the previous !analyze-v output screenshot, athrx.sys has been named in the
current stack. Referencing that driver name in the drivers.txt file you can see that the driver
is Qualcomm Atheros network adapter driver, this is the driver responsible for
the DRIVER_POWER_STATE_FAILURE at system shutdown. Running the lmvm
athrx command shows that the driver is old and needs updating.
Code:
0: kd> lmvm athrx
fffff880`04824000 fffff880`04beb000 athrx T (no symbols)
Loaded symbol image file: athrx.sys
Image path: \SystemRoot\system32\DRIVERS\athrx.sys
Image name: athrx.sys
Timestamp: Thu Oct 25 03:31:15 2012 (5088A473)
CheckSum: 003AF186
ImageSize: 003C7000
PART FOUR
Common Bugchecks and Plans of Attack
There are several bugchecks that appear on a regular basis which should nearly always
require the same course of action, two of them are covered below.
 0x116 (VIDEO_TDR_ERROR)
 0x124 (WHEA_UNCORRECTABLE_ERROR)
0x116
VIDEO_TDR_ERROR
A VIDEO_TDR_ERROR always relates to the system's graphics card (TDR = Timeout Detection
Recovery). This could be down to a number of reasons including drivers, heat, power to the
card, a faulty PCI-e slot or simply a defective GPU. It's in your best interests to employ
common sense trouble shooting techniques in these situations.
 Try later and/or earlier drivers

 Measure the GPU's temperatures at idle and under load
 Ensure the GPU is free from dust build up and that the fan is working
correctly
 Reseat the GPU and check all connections are securely made
 Check PSU voltages in BIOS
 Try a different card in the system
0x124
WHEA_UNCORRECTABLE_ERROR
A 0x124 is one of the worst STOP codes to encounter for the sole reason that the dump files
usually give nothing away as to the cause of the problem. WHEA (Windows Hardware Error
Architecture) errors signify a problem with hardware but very rarely pinpoint the culprit. In
these scenarios it is advised to run a series of hardware stress and diagnostic tests to try and
pinpoint the problem. A template is offered below which covers the four main components
(GPU, CPU, RAM, HDD) and gives you a fighting chance of narrowing down the problematic
device.
Information
While 0x124s are usually caused by defective hardware it has been proven on occasion for
software to be the culprit. See 0x124 software section for information.
To attempt dig deeper into a 0x124 use the !analyze-v command, in the example below
you'll see the PROCESS_NAME: audiodg.exe.
In this particular case there were

also 0x1000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M) dumps which
identified a Logitech Headset driver (dated 2013) as an issue. This tied in with the audio
reference highlighted in the 0x124 so the recommended action would be to update the
driver for the headset, negating the need to stress test components.
If there is no clear indicator within the verbose output run !errrec on Arg2 the Address of
the WHEA_ERROR_RECORD structure.
Again this will often result in a dead end, the !errrec output from the above dump reveals
nothing of use. This is a very common output from this particular command within 0x124s.
Code:
4: kd> !errrec fffffa8008f15028
===========================================================================
====
Common Platform Error Record @ fffffa8008f15028
-------------------------------------------------------------------------------
Record Id : 01d085fcd7041c49
Severity : Fatal (1)
Length : 928
Creator : Microsoft
Notify Type : Machine Check Exception
Timestamp : 5/4/2015 1:21:13 (UTC)
Flags : 0x00000000
===========================================================================
====
Section 0 : Processor Generic
-------------------------------------------------------------------------------
Descriptor @ fffffa8008f150a8
Section @ fffffa8008f15180
Offset : 344
Length : 192
Flags : 0x00000001 Primary
Severity : Fatal
Proc. Type : x86/x64

Instr. Set : x64
Error Type : Cache error
Operation : Instruction Execute
Flags : 0x00
Level :1
CPU Version : 0x0000000000600f20
Processor ID : 0x0000000000000004
Most common STOP ERRORS bug check

Below we will list the most common BSODs, a link to Microsoft’s website and our suggested
work-around.
STOP Error 0x00000001: Drivers are often to blame from 0x001, as they might be conflicting
with software. However, an even more problematic issue is registry related, where
Windows is having problems with its files. We would recommend as a first instance to check
your drivers and if you’re still getting BSODs to run a Windows System Repair.
In extremely rare circumstances, you might find that you’ve got too much RAM installed for
your motherboard or BIOS to handle. Ensure you check the amount of RAM your
motherboard supports (QVL list) and ensure your BIOS is up-to-date.
STOP Error 0x00000005: Often caused by drivers which are either corrupt or not correctly
installed. We suggest re-installing your PC’s drivers to the latest drivers – even if you’ve just
done so. For further guidance, look in the Event Viewer to determine which driver might be
creating the BSOD. Some people have also reported the issue to be related to anti-virus
programs and firewalls – so it might be worth checking those too.
STOP Error 0x0000000A / STOP Error 0x000000D1: These two errors are created by a
multiple variety of problems, making it one of the most annoying BSOD to decipher. It can
be created by device drivers being incompatible or outdated, a Windows system services
making your operating system unstable or even outdated BIOS and incorrect RAM
timings/voltages. We would suggest looking in Event Viewer to see if there are more specific
details you could extract and see if there’s a lead towards your detective work.
STOP Error 0x0000007E: We’ve found the culprits to be antivirus, spyware, malware and
firewall software that create problems within the registry to spring up this BSOD. We don’t
see it often now, with a lot of these programs being compatible and fully updated
automatically, but would suggest looking around for software or ensuring your current
program is up-to-date.
In more extreme cases and for times where there’s a recurrence of BSODs, we would
suggest repairing Windows and checking your disk through CHKDSK (hard drive/SSD). The
BSOD can also spring to life when there’s a problem within the critical Windows files and a
corrupt registry will create problems for Windows.
Finally, a very simple another simple check is to ensure that your boot priority is correct
within your BIOS. The only reason your boot priority might have changed is if you have
previously changed the cables around or updated your BIOS.
STOP Error 0x00000023 / STOP Error 0x00000024: You’ll find these two errors related to
your file system, whereby you’ve either got a corrupt disk or insufficient memory to cope
with your processes. Make sure you’ve got enough RAM in your system for your tasks –
check by looking in Task Manager to see if you’re exceeding your memory capacity.
If you’re still running into problems run CHKDSK and if problems still continue, proceed in
repairing Windows. Read next: How to fix driver issues in Windows 10 & Windows 8.
There are also related BSODs which are caused by RAM issues, these can be caused by
overclocking or having insufficient RAM voltage (which can be increased through the
BIOS): STOP Error 0x0000000A / STOP Error 0x000000D1 / STOP Error 0x0000009C / STOP
Error 0x0000001A / STOP Error 0x0000002E / STOP Error 0x00000050.
http://www.wintips.org/how-to-find-what-causes-blue-screen-of-death-by-reading-bsod-
minidump/
Dell website: What is a blue screen error?

When Windows encounters certain situations, it halts and the resulting diagnostic
information is displayed in white text on a blue screen.
Blue Screen errors occur when:
 Windows detects an error it cannot recover from without losing data
 Windows detects that critical OS data has become corrupted
 Windows detects that hardware has failed in a non-recoverable fashion
Check Problem Reports for problems and solutions

Windows 10 crash errors are collected in Problem Reports and referenced against other
crash data that is available online. To access Problem Reports, follow these instructions:
1. At the desktop, click the Search the web and Windows box and type "problem
reports".
2. Select View all problem reports to view a list of errors that have occurred on your
computer and possible solutions for them, such as updating drivers, flashing your
system BIOS, or checking for updates to software.
3. Under the Source column, look for Windows and under Summary, look for Shut
down unexpectedly.
4. Right-click the line item and select Check for a solution.
You will need to be online in order to view solutions.
Run an online diagnostic

Dell has created a set of online diagnostics that can identify problems with your computer
hardware or configuration that may be causing the issue. Visit the Dell Online Diagnostics to
get more information and run a scan of your computer.
Troubleshooting common blue screen error messages

If your computer reboots immediately after receiving a blue screen error, you can disable
the automatic startup by following these steps:
1. Right-click the Start button and select Properties.
2. Select Advanded system settings.
3. Click the Advanced tab, then under Startup and Recovery, select Settings....
4. Under System failure, uncheck the box next to Automatically restart.
UNMOUNTABLE BOOT VOLUME
INACCESSIBLE BOOT DEVICE

These two errors have similar causes and the same troubleshooting steps apply to both of
them. These stop codes always occur during the startup process. When you encounter one
of these stop codes, the following has happened:
1. The system has completed the Power-On Self-Test (POST).
2. The system has loaded NTLDR and transferred control of the startup process to
NTOSKRNL (the kernel).
3. NTOSKRNL is confused. Either it cannot find the rest of itself, or it cannot read the
file system at the location it believes it is stored.
When troubleshooting this error, your task is to find out why the Windows kernel is
confused and fix the cause of the confusion.
Things to check
 The SATA controller configuration in the system BIOS If the SATA controller gets
toggled from ATA to AHCI mode (or vice versa), then Windows will not be able to talk
to the SATA controller because the different modes require different drivers. Try
toggling the SATA controller mode in the BIOS.
 RAID settings You may receive this error if you've been experimenting with the RAID
controller settings. Try changing the RAID settings back to Autodetect (usually
accurate).
 Improperly or poorly seated cabling Try reseating the data cables that connect the
drive and its controller at both ends.
 Hard drive failure Run the built-in diagnostics on the hard drive. Remember: Code
7 signifies correctable data corruption, not disk failure.
 File system corruption Launch the recovery console from the Windows installation
disc and run chkdsk /f /r.
 Improperly configured BOOT.INI (Windows Vista). If you have inadvertently erased
or tinkered with the boot.ini file, you may receive stop code 0x7B during the startup
process. Launch the recovery console from the Windows installation disc and
run BOOTCFG /REBUILD
NTFS_FILE_SYSTEM
This stop code indicates the NTFS file system driver encountered a situation it could not
handle, and is almost always caused by 3 things:
 Data corruption on the disk
 Data corruption in memory
 The system completely running out of memory (this typically only happens on
heavily-loaded servers)
Things to check
1. Reseat the memory and all drive data cables to eliminate data corruption issues
stemming from poorly or improperly seated hardware.
2. Run a complete memory and hard drive diagnostic. The quick test will not be
thorough enough here. You need to run the full system diagnostic.
3. If those diagnostics pass, run a full file system check from the Recovery Console
(chkdsk /f /r) to detect and (potentially) fix any corrupted data.
4. If none of the above solves the issue, reinstall Windows.
5. If that does not fix the issue, replace the hard drive.
SYSTEM THREAD EXEPTION NOT HANDLED
KERNEL MODE EXCEPTION NOT HANDLED

These two errors indicate that a program running in the kernel encountered an unexpected
condition it could not recover from. They have identical troubleshooting and resolution
steps, and you will probably need to use the Windows Debugger to find out what caused the
error.
Things to check
 If the Blue Screen message mentions a driver or library file, figure out what driver or
application that file is part of and update or disable it.
 Update the system BIOS to the latest available revision.
 Uninstall any recently installed programs, and roll-back any recently installed drivers.
 Run diagnostics on the computer's memory.
PAGE FAULT IN NON PAGED AREA

This stop code means the system tried to access a nonexistent piece of memory, almost
always due to:
 A driver trying to access a page of memory that is not present
 A system service (ex. virus scanner) failing in an exceptional way
 Faulty or incorrectly seated memory
 Corrupted data on the hard drive
Use the Windows Debugger to pinpoint the exact cause of these errors.
Things to check
1. If the Blue Screen error mentions a driver or library file, figure out what driver or
program the file is a part of and either upgrade to the latest version or uninstall the
driver or program.
2. If the error happens during the startup process, try booting to the Last Known Good
Configuration.
3. If the error started appearing after a program or driver was installed, uninstall that
program or driver.
4. Try running a full hard drive and memory diagnostic after reseating the memory and
hard drive data cables.
DRIVER IRQL NOT LESS THAN OR EQUAL TO

This stop code indicates a driver tried to access a certain area of memory when it should not
have, meaning there is a flaw in the driver itself. The goal of your troubleshooting is to find
that driver and either disable or replace it. Use the Windows Debugger to troubleshoot this
error.
Without the debugger, you are limited to uninstalling/updating/rolling back the driver that
contains the driver file the Blue Screen mentions.
THREAD STUCK IN DEVICE DRIVER

This Blue Screen error indicates that a device driver-almost always a video card driver-is
stuck waiting for something (usually a hardware operation) to happen. Most of you have
probably seennv4_disp.sys associated with this Blue Screen.
Things to check:
1. Ensure the video drivers are updated to the latest Dell version.
2. The system BIOS is fully up-to-date.
3. If both the video driver and the system BIOS are fully up-to-date, check with the
manufacturer for recent driver updates.
4. As a last resort, try exchanging the video card.
Note: Reinstalling Windows is not likely to prevent this error from reoccurring.
Additional Information
If these solutions have not resolved your issue, try searching for additional solutions on the
Web.
Click on your preferred search engine below, then describe your problem, including any
specific error messages.
Note: The Microsoft Bug Check Code Reference site has an extensive list of blue screen
error codes descripions and possible causes. If you have recorded your STOP 0xXXXXXX code
and the above steps have not resolved your issue try looking it up on this site.
Search Dell Search Microsoft Search Google Search Bing
Reset or reinstall Windows 10

https://www.bleepingcomputer.com/forums/t/40108/how-to-use-event-viewer/
http://www.pcgamer.com/blue-screen-of-death-survival-guide-every-error-explained/
How to read the small memory dump file that is created by Windows if a
crash occurs
 Email
 Print
Summary
This step-by-step article describes how to examine a small memory dump file. A small
memory dump file can help you determine why your computer crashed.
If you are looking for debug information for Windows 8 or later, please
check http://msdn.microsoft.com/en-
US/library/windows/hardware/ff551063(v=vs.85).aspx
For more information about small memory dump, please

check http://msdn.microsoft.com/en-
us/library/windows/hardware/ff556895(v=vs.85).aspx
Small memory dump files
Click here to show/hide information
If your computer crashes, how can you find out what happened, fix the issue and it
prevent it from happening again? You may find the small memory dump file useful in
this situation. The small memory dump file contains the smallest amount of useful
information that could help you identify why your computer crashed. The memory dump
file contains the following information:
 The Stop message, its parameters and other data
 A list of loaded drivers
 The processor context (PRCB) for the processor that stopped
 The process information and kernel context (EPROCESS) for the process that stopped
 The process information and kernel context (ETHREAD) for the thread that stopped
 The Kernel-mode call stack for the thread that stopped
To create a memory dump file, Windows requires a paging file on the boot volume that
is at least 2 megabytes (MB) in size. On computers that are running Microsoft Windows
2000, or a later version of Windows, a new memory dump file is created each time that a
computer crash may occur. A history of these files is stored in a folder. If a second
problem occurs and if Windows creates a second small memory dump file, Windows
preserves the previous file. Windows gives each file a distinct, date-encoded file name.
For example, Mini022900-01.dmp is the first memory dump file that was generated on
February 29, 2000. Windows keeps a list of all the small memory dump files in the
%SystemRoot%\Minidump folder.
The small memory dump file can be useful when hard disk space is limited. However,
because of the limited information that is included, errors that were not directly caused
by the thread that was running at the time of the problem may not be discovered by an
analysis of this file.
Configure the dump type
To configure startup and recovery options to use the small memory dump file, follow
these steps.
Note Because there are several versions of Microsoft Windows, the following steps may
be different on your computer. If they are, see your product documentation to complete
these steps.
1. Click Start, and then click Control Panel.
2. Double-click System, and then click Advanced system settings.
3. Click the Advanced tab, and then click Settings under Startup and Recovery.
4. In the Write debugging information list, click Small memory dump (64k).
To change the folder location for the small memory dump files, type a new path in
the Dump File box (or in the Small dump directory box, depending on your version of
Windows).
Tools to read the small memory dump file
Use the Dump Check Utility (Dumpchk.exe) to read a memory dump file or verify that the
file has been created correctly.
Note: The Dump Check Utility does not require access to debugging symbols. Symbol
files hold a variety of data which are not actually needed when running the binaries, but
which could be very useful in the debugging process.
For more information about how to use Dump Check Utility in Windows NT, Windows
2000, Windows Server 2003 or Windows Server 2008, see Microsoft Knowledge Base
article 156280: How to Use Dumpchk.exe to check a memory dump file.
For more information about how to use Dump Check Utility in Windows XP, Windows
Vista or Windows 7, see Microsoft Knowledge Base article 315271: How to use
Dumpchk.exe to check a Memory Dump file.
Or, you can use the Windows Debugger (WinDbg.exe) tool or the Kernel Debugger
(KD.exe) tool to read small memory dump files. WinDbg and KD.exe are included with
the latest version of the Debugging Tools for Windows package.
To install the debugging tools, see the Download and Install Debugging Tools for
Windows webpage. Select the Typical installation. By default, the installer installs the
debugging tools in the following folder: C:\Program Files\Debugging Tools for Windows
This Web page also provides access to the downloadable symbol packages for Windows.
For more information about Windows symbols, see Microsoft Knowledge Base
article 311503: Use the Microsoft Symbol Server to obtain debug symbol files311503:
Use the Microsoft Symbol Server to obtain debug symbol files, and the Download
Windows Symbol Packageswebpage.
For more information about dump file options in Windows, see Microsoft Knowledge
Base article 254649: Overview of memory dump file options for Windows 2000, Windows
XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and
Windows Server 2008 R2
Open the dump file
To open the dump file after the installation is complete, follow these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. Change to the Debugging Tools for Windows folder. To do this, type the following at the
command prompt, and then press ENTER:
cd c:\program files\debugging tools for windows
3. To load the dump file into a debugger, type one of the following commands, and then
press ENTER:
windbg -y SymbolPath -i ImagePath -z DumpFilePath
kd -y SymbolPath -i ImagePath -z DumpFilePath
The following table explains the use of the placeholders that are used in these
commands.
Placeholder Explanation
SymbolPath Either the local path where the symbol files have been downloaded or the symbol server path, including a cache folder. Because a
small memory dump file contains limited information, the actual binary files must be loaded together with the symbols for the du
file to be correctly read.
ImagePath The path of these files. The files are contained in the I386 folder on the Windows XP CD-ROM. For example, the path may be
C:\Windows\I386.
DumpFilePath The path and file name for the dump file that you are examining.
Sample Commands
You can use the following sample commands to open the dump file. These commands
assume the following:
 The contents of the I386 folder on the Windows CD-ROM are copied to the
C:\Windows\I386 folder.
 Your dump file is named C:\Windows\Minidump\Minidump.dmp.
Sample 1:
kd -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i c:\windows\i386 -z
c:\windows\minidump\minidump.dmp
Sample 2. If you prefer the graphical version of the debugger instead of the command
line version, type the following command instead:
windbg -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i
c:\windows\i386 -z c:\windows\minidump\minidump.dmp
Examine the dump file
There are several commands that you can use to gather information in the dump file,
including the following commands:
 The !analyze -show command displays the Stop error code and its parameters. The Stop
error code is also known as the bug check code.
 The !analyze -v command displays verbose output.

 The lm N T command lists the specified loaded modules. The output includes the status
and the path of the module.
Note The !drivers extension command displays a list of all drivers that are loaded on
the destination computer, together with summary information about their memory use.
The !drivers extension is obsolete in Windows XP and later. To display information about
loaded drivers and other modules, use the lm command. The lm N T command displays
information in a format that is similar to the old !drivers extension.
For help with other commands and for complete command syntax, see the debugging
tools Help documentation. The debugging tools Help documentation can be found in
the following location:
C:\Program Files\Debugging Tools for Windows\Debugger.chm
Note If you have symbol-related issues, use the Symchk utility to verify that the correct
symbols are loaded correctly.For more information about how to use Symchk, see
Microsoft Knowledge Base article 311503: Use the Microsoft Symbol Server to obtain
debug symbol files.
Simplify the commands by using a batch file
After you identify the command that you must have to load memory dumps, you can
create a batch file to examine a dump file. For example, create a batch file and name it
Dump.bat. Save it in the folder where the debugging tools are installed. Type the
following text in the batch file:
cd "c:\program files\debugging tools for windows"
kd -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i c:\windows\i386 -z
%1
When you want to examine a dump file, type the following command to pass the dump
file path to the batch file:
dump c:\windows\minidump\minidump.dmp
Analyzing a Crash Dump, aka BSOD

★★★★★
★★★★
★★★
★★
★
Juan Antonio Diaz - MSFTMarch 20, 20114


 2
 0
Today I have to face a weird behavior in my laptop since a few of days ago. It only happens that
when the computer goes to sleep, that is, stand-by, either by my request or due to lack of battery,
the screen goes blank but seemed to never finish the sleep process.
I say “seemed” because the last times this happened, I did not have the patience to wait and
long-pressed the power button to force a shutdown. However, last night, I went to bed and left it
in the sleeping attempt, and this morning I found a “nice” crash dump, also known as Blue Screen
Of Death, complaining about DRIVER_POWER_STATE_FAILURE issue:
Sometime ago I had other BSOD that pointed me to a networking drivers issue (ndis.sys), and
updating those available seemed to work and did not get BSOD anymore:
This time, while “DRIVER_POWER_STATE_FAILURE” points initially to a device driver that is

preventing the kernel to suspend the computer, but the BSOD does not show which driver could
it be, so it could be tedious to go and try to update and test every single driver. So lets get into
memory dump analysis to see if we can find the faulty driver.
To do so, the first thing we need is a kernel memory dump. To get so, we need to have the
system configured to do so in “Startup and Recovery” dialog. By default, Windows 7 does not
show BSOD, but restarts the computer after system crash, so if you want to see the BSOD
message, you need to uncheck the “Automatically restart” checkbox.
To analyze the memory dump generated after a BSOD, we can use WinDbg, included with
Windows Debugging Tools. There is great intro and download links at
at http://msdn.microsoft.com/en-us/windows/hardware/gg462988.aspx.
Once we launch WinDbg, the first thing to do is configure the symbols path. We do so from
“File/Symbol File Path”, and specify
“SRV*c:\SymbolsCache*=http://msdl.microsoft.com/download/symbols” as path (without quotes).
This will download symbols from Microsoft to c:\SymbolsCache as needed by WinDbg.
Then we open the crash dump from “File/Open Crash Dump”

In my case, I opened “DRIVER_POWER_STATE_FAILURE.dmp”, as I renamed the dump file to
prevent other dumps to overwrite it.
At the end of the initial output, there is a candidate driver for the BSOD, netw5s64.sys. Executing
“!analyze –v” confirms this fact:
We can see that the error is caused by a device driver blocking an IRP (IoCompleteRequest) for
too long, and we can see that the IRP address is fffffa80101fac10.
If we run !IRP fffffa80101fac10, we can see the drivers involved:

We can again see netw5s64, and this time also Virtual WiFi bus (vwifibus), available in Windows 7
for WiFi hosted networks feature. So here is my supossedly faulty driver:
The point is that it has being working without issues for a long time, so it may not necessary be a
bug in the driver itself, but a hardware failure or a driver configuration. The first thing we can try
though is look for driver updates. We can do this directly from Device Manager. Unfortunately, I
had no luck this time:
Another thing we can try is go to the computer’s integrator website, or even directly to the
driver’s manufacturer website, Intel Corporation in this case, to see if there is a new driver. This
operation can be more or less lengthy, depending on the manufacturer/integrator’s sites
organization and complexity. In my case, my laptop vendor was not providing a good driver
revision (even older than the one I had installed), but Intel did: there was an updated driver not
available in Windows Update:
While I download the updated driver, I take a look at “Power Management” tab of the device
which driver was causing the BSOD in Device Manager, and found the most possible reason for
the failure: The interface is configured to not allow the computer to turn of this device to save
power.
Before updating the driver, I checked this checkbox and try to suspend the computer. Guess what,
this time the computer suspended just fine.
So there is no reason to update the driver…. but …. well…. we all like to be up-to-date … so I’ll
install it anyways
3 Ways to Analyze Memory Dump (.dmp) File

Raymond Updated 4 months ago Windows 8 Comments
The dreaded blue screen of death (BSoD) has been around since Windows 95. It is scary
in a way that this blue screen can happen anytime without the user expecting it and
there is no way to recover from this blue screen other than restarting the computer.
Obviously the biggest problem is actually when you are working on something
important and haven’t got a chance to save it. An unexpected blue screen will just cause
you to lose all or some parts of your work depending on how often it is being saved.
Other than that, the blue screen on an older Windows does look a bit scary with all the
text and technical information on screen. Fortunately the blue screen on Windows 8.1
doesn’t look so frightening.
Anything can cause a blue screen in Windows. It can be from an unstable driver for a
hardware device, 3rd party software such as an antivirus/firewall, or even a rootkit
based malware. It can also be caused by an attacker exploiting or in another word
“nuking” an unpatched Windows. Hardware such as memory, CPU and motherboards
that are failing can also randomly cause blue screen.
If the blue screen is caused by software, an inexperienced computer technician will have
to spend more time to determine the culprit by going through the process of elimination
of disabling all 3rd party programs that startup automatically, enable them one at a time
and test until they experience the blue screen. However with the right tools in hand, it
can quickly reveal which software is possibly causing the blue screen so you can work
towards fixing the problem. Here we have 3 free software that can do
that.1. BlueScreenView
BlueScreenView is a small and portable tool developed by NirSoft that is capable of
quickly showing you which file caused the blue screen. All you need to do is download
the program, run it and it will automatically analyze the minidump files that are created
during the blue screen. The top pane shows the dump files while the lower pane shows
the offending files that caused the crash. If the blue screen is caused by a third party
program, the driver file should be listed in the lower pane.
The drivers that are found in crash stack will be highlighted and those are the files that
you should pay attention to. Double clicking on the driver file listed at the lower pane
will show every detail about the file such as the stack addresses, size, time stamp and
etc. We can see that it was a system file driver belonged to “Resplendence WhoCrashed
Crash Dump Test” that caused the blue screen.
It is also possible to generate an HTML report for sharing or logging purposes. Do take
note that you’ll need to download a separate 64-bit version of BlueScreenView if you
intend to run it on a 64-bit version of Windows.
Download BlueScreenView
2. WhoCrashed
WhoCrashed Home Edition also does pretty much the same thing as BlueScreenView
except it tries to be more user friendly. You’ll need to click the Analyze button to start
analyzing the minidump files and scroll down to see the crash dump analysis report. It
shows you which file probably caused the blue screen and the bug check description
helps the user to understand better. As you can see from the screenshot below, it says
that the crash appears to be a typical software driver bug and is not likely to be caused
by a hardware problem.
The Home Edition is free for home use only. You’ll need to purchase the Pro version if
there is a need to run WhoCrashed in a commercial environment and displaying dump
details, kernel stacks and loaded modules. Although WhoCrashed comes in a setup
installer, it can actually run as a portable program by simply copying the program’s
folder to a USB flash drive and run the executable file.
Download WhoCrashed
3. Manually Analyzing Minidumps

Debugging a program to locate the bug so that the problem can be fixed is not an easy
task and not something every IT person is capable of. The 2 tools mentioned above are
made to be user friendly so that both beginner and expert can tell which offending
driver might have caused the blue screen. Although there are quite a few good third
party debuggers, WinDbg, a free debugging tool by Microsoft is commonly used to
analyze the minidump file and it involves command line usage.
If you do not have WhoCrashed or BlueScreenView at hand, a simple solution is to

analyze the memory dump file online. All you need is a web browser with an internet
connection to visit the webpage, upload the .dmp file and wait for a few seconds for a
report to be automatically generated. Follow the simple steps below to analyze
minidump file online.
3a. Visit OSR Online webpage

3b. Click the “Browse” button and select the .dmp file which is normally located at
C:\Windows\Minidump. If UAC is enabled, you need to copy the .dmp file from the
Minidump folder to another location such as Desktop otherwise you’ll receive an error
message saying that “You don’t have permission to open this file.”
3c. Once you’ve selected the .dmp file to analyze, click the “Upload Dump” button. The
file size of a minidump .dmp file is normally quite small at around 150KB to 300KB so
the upload won’t take very long.
3d. On the analysis report, take note of the MODULE_NAME and IMAGE_NAME which
shows the file or program that caused the crash in Windows.
Additional Notes: If it is a file from a third party program or a driver for a hardware
device, updating or disabling it can stop the blue screen from happening. If it a file from
Windows, there are chances that one of the hardware such as memory, CPU or
mainboard is failing. You should run a memory test first since it is easy to do that by
pressing the Start button and type mdshed which will run the Windows Memory
Diagnostic program.
Read More: https://www.raymond.cc/blog/how-to-analyze-memory-dump-dmp-file/
Is there any way to understand which particular driver has a problem?
After !analyze run k or kd. This will show the stack trace right before the crash. The stack
trace is the list of function calls made right before the crash, with the most recent one at
the top. You should at least be able to learn the filenames of the modules (DLL's)
involved.
I suggest sharing the full results of !analyze and/or the memory dump with people who
are are skilled at WinDbg and are interested in helping. The previously
linked MajorGeeks forum looks like a good place.
This can be accomplished with 7 easy steps:

Step 1. Obtain and install the debugging tools. The links do change over time, but the following
link is currently an exhaustive page which includes Windows Server 2012 and Windows 8
Consumer debugger tools, Windows 7, Vista, XP and Windows Server 2003.
Debugging Tools Windows
All you need to install is the “Install Debugging Tools for Windows as a Standalone Component
(from Windows SDK)” and during the install only select "Debugging Tools for
Windows". Everything else is used for more advanced troubleshooting or development, and isn’t
needed here. Today I followed the link to “Install Debugging Tools for Windows as a Standalone
Component (from Windows SDK)” although for a different OS you may need to follow a different
link.
Step 2. From an elevated command prompt navigate to the debugging folder. For me with the
latest tools on Windows Server 2012 it was at C:\Program Files (x86)\Windows
Kits\8.0\Debuggers\x64\. You can specify the path during the install.
Step 3. Type the following:
kd –z C:\Windows\memory.dmp (or the path to your .dmp file)
.logopen c:\debuglog.txt
.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
.reload;!analyze -v;r;kv;lmnt;.logclose;q
Step 7. Review the results by opening c:\debuglog.txt in your favorite text editor. Searching for
PROCESS_NAME: will show which process had the fault. You can use the process name and
other information from the dump to find clues and find answers in a web search. Usually the fault
is with a hardware drivers of some sort, but there are many things that can cause crashes so the
actual analyzing of the dump may take some research.
Often times a driver update will fix the issue. If the summary information doesn’t offer enough
information then you’ll need to dig further into the debugging tools or open a CSS case with
Microsoft. The steps above will provide you with a summary mostly-human-readable report from
the dump. There is much more information available in the memory dump although it gets
exponentially more difficult to track down the details the further you get into windows debugging.
Hopefully these quick steps are helpful for you as you troubleshoot the unwelcome BSOD.
Microsoft Windows 7 Crashes, Restarts or a Blue

Screen Appears
Table of Contents:
1. What Is a Blue Screen Error?
2. Run an online diagnostic
3. Troubleshooting Common Blue Screen Error Messages
a. 0x000000ED and 0x0000007B
b. 0x00000024
c. 0x0000007E and 0x0000008E
d. 0x00000050
e. 0x000000D1
f. 0x000000EA
4. Using the Windows Debugger
This article describes what Blue Screen errors are, why they occur, how to recognize them, and
how to resolve some of the more common error messages.
This article is specific to Microsoft Windows 7.

Click below to change the operating system.
 Windows 10
 Windows 8
 Windows Vista
 Windows XP
Dell Recommended:
Resolving stop (blue screen) errors in Windows 7 (Microsoft Content)
Video (English Only) - Troubleshoot Blue Screen Issues in Windows
What Is a Blue Screen Error?

When Windows encounters certain situations, it halts and the resulting diagnostic information is
displayed in white text on a blue screen. The appearance of these errors is where the term "Blue
Screen" or "Blue Screen of Death" has come from.
Blue Screen errors occur when:
 Windows detects an error it cannot recover from without losing data

 Windows detects that critical OS data has become corrupted
 Windows detects that hardware has failed in a non-recoverable fashion
 The exact text displayed has changed over the years from a dense wall of information in
Windows NT 4.0 to the comparatively sparse message employed by modern versions of
Windows.
Run an online diagnostic

Dell has created a set of online diagnostics that can identify problems with your computer
hardware or configuration that may be causing the issue. Visit the Dell Online Diagnostics to get
more information and run a scan of your computer.
Troubleshooting Common Blue Screen Error Messages

Stop 0x000000ED (UNMOUNTABLE_BOOT_VOLUME)
Stop 0x0000007B (INACCESSIBLE_BOOT_DEVICE)
These two errors have similar causes and the same troubleshooting steps apply to both of them.
These stop codes always occur during the startup process. When you encounter one of these
stop codes, the following has happened:
1. The system has completed the Power-On Self-Test (POST).

2. The system has loaded NTLDR and transferred control of the startup process to
NTOSKRNL (the kernel).
3. NTOSKRNL is confused. Either it cannot find the rest of itself, or it cannot read the file
system at the location it believes it is stored.
When troubleshooting this error, your task is to find out why the Windows kernel is
confused and fix the cause of the confusion.
Things to check
 The SATA controller configuration in the system BIOS If the SATA controller gets toggled
from ATA to AHCI mode (or vice versa), then Windows will not be able to talk to the
SATA controller because the different modes require different drivers. Try toggling the
SATA controller mode in the BIOS.
 RAID settings You may receive this error if you've been experimenting with the RAID
controller settings. Try changing the RAID settings back to Autodetect (usually accurate).
 Improperly or poorly seated cabling Try reseating the data cables that connect the drive
and its controller at both ends.
 Hard drive failure Run the built-in diagnostics on the hard drive. Remember: Code
7 signifies correctable data corruption, not disk failure.
 File system corruption Launch the recovery console from the Windows installation disc
and run chkdsk /f /r.
 Improperly configured BOOT.INI (Windows Vista). If you have inadvertently erased or
tinkered with the boot.ini file, you may receive stop code 0x7B during the startup process.
Launch the recovery console from the Windows installation disc and run BOOTCFG
/REBUILD
STOP 0x00000024 (NTFS_FILE_SYSTEM)
This stop code indicates the NTFS file system driver encountered a situation it could not handle,
and is almost always caused by 3 things:
 Data corruption on the disk

 Data corruption in memory
 The system completely running out of memory (this typically only happens on heavily-
loaded servers)
Things to check
1. Reseat the memory and all drive data cables to eliminate data corruption issues
stemming from poorly or improperly seated hardware.
2. Run a complete memory and hard drive diagnostic. The quick test will not be thorough
enough here. You need to run the full system diagnostic.
3. If those diagnostics pass, run a full file system check from the Recovery Console (chkdsk
/f /r) to detect and (potentially) fix any corrupted data.
4. If none of the above solves the issue, reinstall Windows.
5. If that does not fix the issue, replace the hard drive.
STOP 0x0000007E (SYSTEM_THREAD_EXEPTION_NOT_HANDLED)

STOP 0x0000008E (KERNEL_MODE_EXCEPTION_NOT_HANDLED)
These two errors indicate that a program running in the kernel encountered an unexpected
condition it could not recover from. They have identical troubleshooting and resolution steps, and
you will probably need to use the Windows Debugger to find out what caused the error.
Things to check
 If the Blue Screen message mentions a driver or library file, figure out what driver or
application that file is part of and update or disable it.
 Update the system BIOS to the latest available revision.
 Uninstall any recently installed programs, and roll-back any recently installed drivers.
 Run diagnostics on the computer's memory.
STOP 0x00000050 (PAGE_FAULT_IN_NON_PAGED_AREA)

This stop code means the system tried to access a nonexistent piece of memory, almost always
due to:
 A driver trying to access a page of memory that is not present

 A system service (ex. virus scanner) failing in an exceptional way
 Faulty or incorrectly seated memory
 Corrupted data on the hard drive
Use the Windows Debugger to pinpoint the exact cause of these errors.
Things to check
1. If the Blue Screen error mentions a driver or library file, figure out what driver or program
the file is a part of and either upgrade to the latest version or uninstall the driver or
program.
2. If the error happens during the startup process, try booting to the Last Known Good
Configuration.
3. If the error started appearing after a program or driver was installed, uninstall that
program or driver.
4. Try running a full hard drive and memory diagnostic after reseating the memory and hard
drive data cables.
STOP 0x000000D1 (DRIVER_IRQL_NOT_LESS_THAN_OR_EQUAL_TO)

This stop code indicates a driver tried to access a certain area of memory when it should not
have, meaning there is a flaw in the driver itself. The goal of your troubleshooting is to find that
driver and either disable or replace it. Use the Windows Debugger to troubleshoot this error.
Without the debugger, you are limited to uninstalling/updating/rolling back the driver that contains
the driver file the Blue Screen mentions.
STOP 0x000000EA (THREAD_STUCK_IN_DEVICE_DRIVER)

This Blue Screen error indicates that a device driver-almost always a video card driver-is stuck
waiting for something (usually a hardware operation) to happen. Most of you have probably
seen nv4_disp.sys associated with this Blue Screen.
Things to check:
1. Ensure the video drivers are updated to the latest Dell version.
2. The system BIOS is fully up-to-date.
3. If both the video driver and the system BIOS are fully up-to-date, check with the
manufacturer for recent driver updates.
4. As a last resort, try exchanging the video card.
Reinstalling Windows is not likely to prevent this error from reoccurring.
Using the Windows Debugger

The Windows Debugger is one of the primary tools used by Microsoft software developers and
support staff to analyze and resolve errors that result in memory dumps, and it's available for you.
The Windows Debugger is a powerful tool with many useful applications, but for this article, we
are only interested in its ability to analyze memory dump files generated by blue screen errors to
determine the cause of the error.
Before you can use the tool, keep in mind the following:
 The Windows Debugger is not a native Windows tool. You must download and install the
application (15 MB) from the Microsoft web site. Administrator access is required to install
the tool.
 The Debugger requires some minor customization before use.
 The Debugger can take anywhere from 30 seconds to two minutes to fully analyze a
memory dump.
To use the tool, follow these steps:
1. Download and install the Windows Debugger from the Microsoft Web Site .
If you use Google to search for "windows debugger," the first link returned will be the
Windows Debugger home page.
2. Once installation completes click Start, click All Programs, click Debugging Tools for
Windows, then click WinDbg to open the Windows Debugger.
3. Configure the symbol path used by the debugger to turn addresses in the memory dump
file into meaningful location names: expand the File menu, select Symbol File Path, type
"SRV*c:\debug_symbols*http://msdl.microsoft.com/download/symbols" in the dialog box
then click OK.
4. Open a minidump file: expand the File menu, select Open Crash Dump, select the
desired dump file and click Open.
The system usually stores minidump files in

either: C:\WINNT\Minidump\ or C:\Windows\Minidump\. The files will be
named miniMMDDYY-NN.dmp, where MMis the month, DD is the day, and YY is the year
in which the dump file was created. NN is the sequence the dump files were created in if
multiple dumps were generated on the same day (the first crash dump on a given day will
be numbered 01, the second 02, etc.).
5. The debugger will open the dump file and give a brief description of what caused the
system to crash. (Figure 2)
The first time you use the Debugger to open and dump file on a system, it will take a few
minutes to download symbol information in the background before it returns any
information.
Figure 2: Windows Debugger
Suggested command for the Debugger's command line
Stop code from the blue screen (1000007F is the same as 0x7F)
What Windows thinks caused the crash (atapi.sysin this example, you will
sometimes see things like memory_corruption
6. When it returns this preliminary analysis, the Debugger tells you how to dig deeper. Type
"!analyze -v" in the command line (kd>) field at the bottom of the window and press
theEnter key to have the WinDbg perform a detailed analysis of the file.
The results will be lengthy, and you may have to scroll vertically within the Debugger's
window to locate all the pertinent information.
Figure 3: Analyze the Results
A detailed explanation of the stop code (in the example, you can see that the kernel
encountered an EXCEPTION_DOUBLE_FAULT (8), or an error while trying to process
an error)
Figure 4: Further Analysis of the Results
The bug check code (notice in the example it includes the number 8, indicating the
double fault)
The number of times the system has crashed with this exact error (typically 1)
The bucket in which Windows has categorized the crash
The stack trace at the time the system crashed, with the most recently called
procedure on top (you can see in the example the system crashed while processing a
request from the IDE controller)
Figure 5: Additional Analysis
The name of the module the system was in when it crashed. On an actual system,
the module name is a link you can click to receive some useful information about the
module, who created it, how old it is, etc
Conclusion
The problem creating the BSOD was caused by the installed dialer software for a USB
modem. It turned out that uninstalling the software didn't resolve the problem.
The answer to the problem was achieved by using the WinDBG tool to Debug and analyze
the memory dump file. The fix was to rename the C:\Windows\System\fldevice.sys driver
to C:\Windows\System\fldevice.sys.old. Windows was still referencing the file even though
the software had been uninstalled. This tool is invaluable and will help you to resolve the
problems that you may encounter when you get a BSOD.
https://www.tenforums.com/tutorials/5558-windbg-basics-debugging-crash-dumps-
windows-10-a.html
Analyzing Windows Crash Dump Files
logicchild, 31 Oct 2008 CPOL
4.00 (8 votes)
1 2 3 4 5
4.00/5 - 8 votes
μ 4.00, σa 1.83 [?]
Rate this: vote 1vote 2vote 3vote 4vote 5

An article that focuses on how to analyze a crash dump file.
Introduction
This article will focus on using the Debugging Tools for Windows in order to analyze a crash
dump. The intention therein is to encourage the reader to use these techniques if his or her
system crashes. It is entirely possible to offer this as a learned skill to those who have systems
that crash a lot. Analyzing a crash dump file that is generated by the Operating System can be an
easy task once a few of the necessary principles are understood, as well as the tools needed to
perform an analysis. Tools are needed for analyzing crash dumps. The tools needed to analyze a
crash dump would be the Debugging Tools for Windows debuggers. After installing those tools,
you would download the symbols files to cache them locally. During the debugging process,
these symbol files can also be downloaded from the Microsoft Symbol Server by setting the path
to the environment:
Hide Copy Code

set PATH=srv*c:\symbols*http://msdl.microsoft.com/download/symbols
You should use the /M switch at the end of the line when running Vista. Notice how the symbols
are cached locally in a directory called c:\symbols. But, what are symbols? Symbols are made
when a program is being built, the compilation process translates the human-readable source
code to the machine’s assembly language. This code is normally used to build an object file,
which contains a symbol table describing all the objects in the file that have external linkage.
Symbols refer to variables and functions in the running program by the names given to them by
the programmer in the source code. In order to display and interpret these names, the debugger
requires information about the types of the variables and functions in the program, and about
which instructions in the executable file correspond to which lines in the source code files. Such
information takes the form of a symbol table, which the compiler and linker include in the
executable file during the linking process to build that executable. Therefore, the downloaded
symbols would be for Microsoft code alone. As we will see, a third party driver will not have
symbols, and also uses a calling convention that omits a stack frame pointer. This third party
driver would call an Operating System function and that would cause the crash, but it is likely that
the third party driver passed the function some erroneous data. Having said that, another
powerful debugger is the livekd.exe written by Mark Russinovich. As we will see, he is also the
author of the tool that causes a crash for the educational sake of how to analyze crash dump files
and put that knowledge to practical use.
Before we discuss these tools and how they are used, we must first understand that normally
when the system crashes, something went wrong in the kernel mode. A device driver or an
Operating System function running in kernel-mode incurs an unhandled exception, such as a
memory access violation, an example of which would be either an attempt to write to a read-only
page, or an attempt to read an address that isn’t currently mapped and is therefore not a valid
memory location. Stated loosely, an executing thread attempts to or does write to a memory
block that it does not own and corrupts the state of that memory block.
Crash dump analysis resides under the topic of memory analysis. A fundamental aspect of
memory analysis is that the locations of data used by the Operating System are not the same as
the physical locations needed to locate data in a memory dump. Because there is generally not
enough physical memory to contain all running processes simultaneously, the Windows
Operating System must simulate a larger memory space. This is why configuring a full memory
dump is not very practical, as user mode code and data are normally not used for crash dump
analysis. If something went wrong in kernel mode, then configuring a kernel dump crash file
would be the best choice to analyze a system crash. These settings are found in the Advanced
Settings tab on the applet in the Control Panel that also contains the device manager and the
remote settings.
A Brief Look at Threads and Processes

A thread is a unit of execution context. Threads are the units of scheduling, and contain the
execution state: the register values, the instruction pointer, and the stack pointer. A process is a
container that has at least one thread, a handle table, a security token, and an address space.
Threads share the private address space, so it is up to the programmer to synchronize access to
shared data within the address space among these threads. In fact, part of the Windows memory
protection scheme is premised on the fact that when a process (threads within) is executing, the
address space of that process is mapped into the microprocessor’s memory management
hardware. Therefore, a process can’t see the address space of another process by virtue of the
fact that it is not present—it is currently not loaded into the microprocessor’s memory
management hardware. This does not mean that it cannot access the address space of another
process. In order to do so, it has to follow Windows security principles, open that process, and
use special APIs to gain access to that remote process’s address space.
The Windows Memory Manager creates the illusion of a flat virtual address space, when in fact,
the hardware unit of the microprocessor maps the virtual address space to the physical address.
This larger memory space simulation is achieved by creating a virtual address space for each
process that is translated to physical storage locations through a series of data structures. The
main data structures are the page directory and the page table. Mapping the virtual address
space to the physical address is done so in the granularity of a page (4 kilobytes of physical
memory). When a user mode application needs to map its code and data onto the virtual address
space, the process may represent to the system an instance of a running program. But, as an
application needs to map its code and data onto the virtual address space, the actual Operating
System also needs to map itself, as well as the configured device drivers, and the data that is
used by device drivers that is stored on the kernel-mode heap. The virtual address used by a
process does not represent the actual physical location of an object in memory. Instead, the
system maintains a page map for each process, which is an internal data structure used to
translate virtual addresses into corresponding physical addresses.
Another thing about memory protection is that the address space consists of both the user's
address space as well as part of the address space that is dedicated towards mapping the kernel,
the drivers, and the data they both use. It would pose a security risk if user mode components
like Notepad could reach into kernel mode and read the data out of there or even modify it. For
this reason, Windows relies on the help of the memory management hardware to mark pages
that represent kernel address space as being system pages. User process memory addresses are
separate, as all kernel mode components share a single address space: user threads cannot
access kernel memory.
The memory management hardware on processors that Windows run on prevent anything
running in user mode from accessing pages that are marked as system pages. So, in order for a
thread to make a system call and thus enter Operating System code and access kernel memory, a
transition has to occur. When a thread has to make a system call, that thread makes a call
function in a DLL that performs a special instruction that safely transitions into this elevated
processor access mode. On an x86 architecture, this elevated processor access mode is called
Ring 0. So, kernel-mode code runs in ring 0, and user mode code runs in ring 3. Threads are
constantly switching back and forth from user-mode to kernel-mode and back every time they
make a system call. When that switch is made, the thread is now executing in kernel mode, and
now the Operating System and the drivers have access to that kernel-mode protected memory.
Interrupt Request Levels: IRQLs

x86 interrupt controllers perform a level of interrupt prioritization, but Windows imposes its own
interrupt priority scheme known as interrupt request levels (IRQLs). This scheme is actually a
software concept that is used by Windows to prioritize its own work. It is basically the priority of
what's happening on the processor at that point. There are a few IRQLs that are normally related
to crashes. One is the lowest level, and is called the PASSIVE_LEVEL, during which no interrupts
are masked: no software or hardware interrupts are masked. By definition, when the system is
running user-mode code, the IRQL is at PASSIVE_LEVEL. The only time an IRQL can be elevated
to higher levels is if the system is executing kernel mode code in response to software generated
interrupts or hardware generated interrupts that trigger the execution of interrupt service
routines or deferred procedure calls. Even when running kernel-mode code, the system tries to
keep the IRQL at PASSIVE_LEVELbecause it is more responsive to devices that are interrupting
the system to keep their interrupts unmasked. The next IRQL relevant to system crashes is
the DISPATCH_LEVEL. DISPATCH_LEVEL is the highest software interrupt level, and scheduler
operations are mapped to this level. When the scheduler is operating on the system, it raises the
IRQL to DISPATCH_LEVEL. Other operations can raise the IRQL to DISPATCH_LEVEL, but when
another operation raises the IRQL to DISPATCH_LEVEL, the scheduler is disabled. A way that a
thread running in kernel mode can ensure that it is not preempted by another thread on that
processor is to raise the interrupt level to DISPATCH_LEVEL. This turns off the scheduler, and
now that thread can run through whatever operation is performing to completion. When it is
done, it drops the interrupt level down to PASSIVE_LEVEL and re-enables the scheduler. A side
effect of having the scheduler off at DISPATCH_LEVEL is that a driver executing
at DISPATCH_LEVEL or a level higher cannot take a page fault. It cannot reference a piece of
memory that is marked as pageable that is not present because to do so would trigger the
memory manager in the page-in handler, which would be forced to issue a disk I/O (hard fault). It
would then suspend that thread until the I/O is complete, until the data that was referenced has
been brought in from disk (either a mapped file or a page file). In that process of placing the
thread in a wait state, it is basically calling the scheduler and informing it that it must find
another thread to run on the CPU. But at DISPATCH_LEVEL, the scheduler is off. This is a
violation of the Windows internal synchronization architecture, and thus by the system, an illegal
operation.
The Stack in Contrast with the Heap

The stack is an abstract data structure that is read recursively, from bottom to top. The heap is a
dynamically allocated amount of memory used for building programs when the size of their data
structures cannot be determined statically. That is, the data structures will grow and shrink as the
program dictates the need for heap allocations. The heap grows from the lower memory
addresses to the higher addresses, a manner of opposite of that of the stack. It is not possible for
the heap and the stack to run into each other. The data section of an application program stores
global and static variables on the heap. The BSS section of an application program stores globally
initialized variables on the heap. The stack represents the data that the hardware records and that
the device drivers that are calling Operating System functions record that allow nested function
invocation. So, when a device driver calls the Operating System, its information that is stored in
the stack is used to pass parameters to the Operating System and return back to the function
that called it. So, the stack stores the parameters passed, the return address, and local variables
(information local to the function that is processing the request). In Windows, each thread has
two stacks: one for user-mode execution of the thread, and the stack that resides in the user
address space and therefore is accessible to any thread in the process. When a thread enters
kernel-mode, having invoked a system call, that thread now runs off of its kernel mode stack. The
kernel mode stack resides in the kernel address, and therefore is not accessible to the threads
running in user mode.
The return address is saved at the time when Function 1 makes its call to Function 2. That is what
the hardware saves, so that when Function 2 returns, the hardware knows where it should pick up
execution inside of Function 1. Function 2, after it is called, begins by setting up its frame pointer.
It saves that to the stack; it might use some local buffers that it wants to use temporarily while it
is executing. These local buffers are allocated on the stack and are seen as Local Variable 1 and
Local Variable 2. Function 2, when it calls Function 3, passes the arguments to the function on the
stack in the same way it was passed arguments. The stack frame pointers clearly delineate the
areas that correspond to each of the functions in that nesting.
The scenario above illustrates a very simple calling convention for the debugging analysis engine
to analyze. Other calling conventions are different, however. Once the calling convention inside
the kernel itself is called, the frame pointer is omitted: no frame pointer is pushed onto the stack,
making it difficult for the analysis engine in the debugger unless the analysis has symbols. The
analysis engine has symbols for all of Microsoft code, but if you have third party drivers on the
stack and they are using calling conventions that don't use the frame pointer, it is difficult for the
analysis engine to figure out where the stack frames are.
When you open up a crash dump file in the Windows debugger, it performs a basic analysis, and
essentially makes a guess as to who the culprit is. When you open the debugger, it internally
invokes a command that you can explicitly use, called !analyze (!analyze -v load). !Analyze
displays the stop code and parameters and a guess at the offending driver. !Analyze basically
looks at the stack. Sometimes, the bug check parameters point to the instruction pointer (cs:ip)
that is the offending instruction. Using the loaded module list (the !lm command), it can
determine what driver that instruction fits. In other cases, !analyze uses heuristics to walk the
stack and determine what was happening at the time of the crash, and then performs a sort of
profiling. If the crash occurred inside of the Operating System but a caller of the function of the
Operating System that triggered the crash was a third party driver, the debugger might guess
and state that the crash was probably caused by .. and then point the finger at the third party
driver even though the crash itself might have been caused by a Windows Operating System
function. But, it is very likely that the called function was passed some erroneous data (a pointer
to a corrupt data structure, or some parameter that was invalid). If the debugger states that the
crash was by, say, ntokrnl.exe, or some file system driver, don't believe it. Microsoft has gathered
multitudes of data involving crashes and has the data to prove that at least 80% of the crashes
are caused by 3rd party device drivers. This means that you have to do more digging.
Mark Russinovich, who is now employed by Microsoft, wrote an application called
“Notmyfault.exe” that is downloadable freeware in a zip file. The purpose of this application is
solely meant for educational purposes to help users and the like learn how to analyze and
interpret a crash dump file. When the Operating System sees something wrong that is out of any
legal bounds, it will call an Operating System function called KernelBugEx(documented in the
Windows DDK). This function takes the stop code and four parameters that are interpreted in a
per-stop code basis. KernelBugCheckEx masks out all interrupts on all processors in the
displays to then switch the display mode into a low-resolution VGA graphics mode, which then
lets the system paint a blue screen. The example that will be shown below describes some of the
contents of the blue screen while the memory dump begins, dumping physical memory to disk.
You can use the Notmyfault utility to generate a crash. You simply select the type of Operating
System scenario that would cause a system crash:
 High IRQL (kernel mode)

 Buffer Overflow
 Code Overwrite
 Stack Trash
 High IRQL (user mode)
 Deadlock
 Hang
Choosing the High IRQL (kernel mode) crash and click “do bug” will cause the driver to allocate a
page of paged pool, raise the IRQL to above the DPC (Deferred Procedure
Call) DISPATCH_LEVEL to then touch the page it has freed. If a crash does not happen
immediately, the process continues by reading memory past the end of the page until it causes a
crash by accessing invalid pages. More to the point, the driver allocates a paged pool buffer,
frees the buffer, raises the IRQL to greater than or equal to DISPATCH_LEVEL, and then touches
that buffer and the pages that follow. Pages in memory that are accessed at
IRQLs DISPATCH_LEVEL or above must be physically present. The crash occurs and the blue
screen depicts the DRIVER_IRQL_NOT_LESS_THAT_OR_EQUAL and begins dumping memory to
the page file. Stated loosely, when the system reboots, the smss.exe (Session Manager) looks at
the page file to see if there is a crash dump file. It will, in turn, call a function to make another
process copy the crash file and write it to %systemroot%. So, with our symbols configured in the
WinDbg tool, we use the Notmyfault utility, but ideally in a virtual environment. The writer of this
paper strongly recommends that the student of crashes download a trial version of VMWare
Workstation for Windows, where another installation of Windows can be installed to create an
artificial computing environment. This virtual environment would be a software layer that
functions as an abstraction to provide a computing environment that would be completely
separated from your Operating System. Even spyware in a virtual environment cannot get to the
outer computer.
After the blue screen appears, the system reboots, and we open the crash file that should reside
in the Windows directory: c:\Windows\MEMORY.dmp. Open this file when you choose the “open
crash file” choice of the File menu on the WinDbg toolbar:
Hide Copy Code

Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: c:\symbols;srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Hide Copy Code
Executable search path is:
Windows Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6001.18145.x86fre.vistasp1_gdr.080917-1612
Kernel base = 0x81a4c000 PsLoadedModuleList = 0x81b63c70
Debug session time: Sat Nov 1 01:08:53.731 2008 (GMT-4)
Hide Copy Code
System Uptime: 0 days 4:07:49.287
Loading Kernel Symbols
.......................................................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffd500c). Type ".hh dbgerr001" for details
Loading unloaded module list
Hide Copy Code
BugCheck D1, {bec0c5e8, 1c, 0, b80493dd}
Use !analyze -v to get detailed debugging information.
Notice that the error message states that no symbol information could be loaded: Microsoft did
not write this driver, as myfault.sys is a third party driver.
Hide Copy Code

*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Page 52f17 not present in the dump file. Type ".hh dbgerr004" for details
Probably caused by : myfault.sys ( myfault+3dd )
Now, we explicitly issue the !analyze debugger command in verbose mode:
Hide Copy Code

0: kd> !analyze –v
The IRQL_NOT_LESS_THAN_OR_EQUAL is a common stop code that states that an attempt was
made to reference a page of memory that was not present:
Hide Shrink Copy Code

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: bec0c5e8, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: b80493dd, address which referenced memory
Debugging Details:
------------------
Page 52f17 not present in the dump file. Type ".hh dbgerr004" for details
READ_ADDRESS: bec0c5e8 Paged pool
CURRENT_IRQL: 1c
FAULTING_IP:
myfault+3dd
b80493dd 8b06 mov eax,dword ptr [esi]
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: NotMyfault.exe
TRAP_FRAME: aaf75b78 -- (.trap 0xffffffffaaf75b78)
ErrCode = 00000000
eax=bec0b5e8 ebx=83cf7138 ecx=b74e421c edx=83625088 esi=bec0c5e8 edi=00000000
eip=b80493dd esp=aaf75bec ebp=aaf75c44 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
myfault+0x3dd:
b80493dd 8b06 mov eax,dword ptr [esi] ds:0023:bec0c5e8=????????
Resetting default scope
Note that the question marks indicate inaccessible memory, and that the faulting IP (instruction
pointer) points at the address that corresponds to the module that caused the crash.
Hide Copy Code

LAST_CONTROL_TRANSFER: from b80493dd to 81aa6d24
STACK_TEXT:
aaf75b78 b80493dd badb0d00 83625088 00000003 nt!KiTrap0E+0x2ac
WARNING: Stack unwind information not available. Following frames may be wrong.
aaf75c44 81c98615 840bebd8 83cf7120 83cf7190 myfault+0x3dd

aaf75c64 81c98dba 83decf08 840bebd8 00000000 nt!IopSynchronousServiceTail+0x1d9
aaf75d00 81c82a8d 83decf08 83cf7120 00000000 nt!IopXxxControlFile+0x6b7
aaf75d34 81aa3a1a 00000080 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
aaf75d34 77bf9a94 00000080 00000000 00000000 nt!KiFastCallEntry+0x12a
0012f9f4 00000000 00000000 00000000 00000000 0x77bf9a94
Notice that the bottom of the stack contains the instruction 0x77bf9a94 that transitioned into
kernel mode. The instruction above, nt!KiFastCallEntry+0x12a calls nt!DeviceIoControlFile+0x2a
(related to the IOCTLs in the system), which calls nt!IopSynchrounousServiceTail+0x6b7, that,
finally winds up at the device driver myfault.sys referencing invalid memory. The stack
information shows that running the executable in user mode results in the bottom instruction
that enters into kernel mode after the thread makes a system function call. This invokes
the DeviceIoControl function in kernel32.dll, and so on. The module “nt” that precedes the
system functions stands for Ntsokrnl.exe (the kernel). So, when the debugger performs an analysis,
it sees the instruction that transitioned into kernel mode, then nt, and up to myfault. It recognizes
“nt” as the standing for the kernel image and says to itself, that is ours, so keep tracing recursively.
Hide Copy Code

STACK_COMMAND: kb
FOLLOWUP_IP:
myfault+3dd
b80493dd 8b06 mov eax,dword ptr [esi]
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: myfault+3dd
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: myfault
IMAGE_NAME: myfault.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 453143ee
FAILURE_BUCKET_ID: 0xD1_myfault+3dd
BUCKET_ID: 0xD1_myfault+3dd
If the driver is not as familiar (or as obvious) as myfualt.sys, then use the lm (list modules)
command to look at the driver’s version information. Add the k (kernel modules) and
the v (verbose) options along with the m (match) option followed by the name of the driver and a
wildcard:
Hide Copy Code

0: kd> lm kv m myfault*
b8049000 b8049ec0 myfault (no symbols)
Loaded symbol image file: myfault.sys
Image path: \??\C:\Windows\system32\drivers\myfault.sys
Image name: myfault.sys
Timestamp: Sat Oct 14 16:09:18 2006 (453143EE)
CheckSum: 0000295E
ImageSize: 00000EC0
File version: 2.0.0.0
Product version: 2.0.0.0
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Sysinternals
ProductName: Sysinternals Myfault
InternalName: myfault.sys
OriginalFilename: myfault.sys
ProductVersion: 2.0
FileVersion: 2.0
FileDescription: Crash Test Driver
LegalCopyright: Copyright (C) M. Russinovich 2002-2004
Despite the fact the example above is a basic example that uses a test crash driver to generate a
crash and a crash file, the techniques involved can often be used in other situations. Should your
system crash and you see a device driver that is the culprit and the crashes are regular, go to the
website of the device driver. It may be that your current version is outdated, and the driver has
been updated several times. Download that driver and see if the system still crashes. Perhaps,
some third party device driver companies can also offer symbol files for debugging information.
BSOD after during windows logo on boot

Changed the bios settings of Hard disk from ATA to AHCI.
zw32087Sep 14, 2012, 2:28 PM

Let me apologize in advance for the long post, however, I'm just trying to include as much
information in this first post to expedite the process.
As the title says, halfway through the windows logo on boot, computer blue screens very
quickly, to the point that I can't even read what is on the screen. This is a new build that I
just completed today with all new components except for the HDD, which is from my old
computer.
History:
Brand new build that has yet to work properly. However, I am attempting to recycle the
HDD from my old computer. When I boot the computer up, the BIOS screen flashes and I
can access the BIOS menu. However, when it goes past the BIOS flash screen, I'm presented
with a Windows Error Recovery screen with two options: Launch Startup Repair
(recommended) and Start Windows Normally. The exact text on the Windows Error
Recovery screen is as follows
"Windows failed to start. A recent hardware or software change might be the cause. If
Windows files have been damaged or configured incorrectly, Startup Repair can help
diagnose and fix the problem. If power was interrupted during startup, choose Start
Windows Normally. (Use the arrow keys to highlight your choice.)"
When selecting the first option, Startup Repair, it takes me to a windows screen with a box
pop-up that says:
"Startup Repair is checking your system for problems... If problems are found, Startup
Repair will fix them automatically. your computer might restart several times during this
process. No changes will be made to your personal files or information. This might take
several minutes."
I let this process go for two or three minutes at which point another box pops up that says:
"Do you want to restore your computer using System Repair? Startup Repair can try to
restore your computer to an earlier point in time when it worked correctly. This repair will
not change personal data, but it might remove some programs that were installed recently.
You cannot undo this restoration."
I attempted this option only to have the computer sit at the attempted recovery screen for
about 20 minutes (because there is no previous point where the computer worked as it's a
new build)
When I select the second option, it simply does the exact same thing as before, gets halfway
through the windows logo, freezes, and flashes a BSOD for about 1 second before
rebooting.
Specs:
CPU: Intel Core i7-3770K, 3.50 GHz, 8MB Cache, LGA1155, 77W
Motherboard: Asus P8Z77-V Pro
RAM: G.Skill Ares 4GB DDR3-1600 CL9-9-9-24 1.50v (4 total)
CPU Cooler: Stock
Video Card: EVGA GEFORCE GTX 660Ti
Power Supply: Corsair TX750M
Hard Drive: Seagate Barracuda 7200.11 1000 Gbytes (This is from my previous computer)
Operating System: Windows 7 Home Premium 64 bit already on HDD
Case: Corsair 400R
Other: 2 aftermarket Antec 120mm fans. One on side panel for intake, one on top for
exhaust. However, only the top fan is connect currently as both side panels are not on the
case
Steps Taken:
1. I covered this step in the History portion, however, just to briefly reiterate, I tried using
the System Repair tool to detect and fix the issue, didn't work.
2. Attempted to use the System Repair tool to restore my system, didn't work.
3. Googled the problem and came across this
guide, http://www.tomshardware.com/forum/261145-31-perform-steps-posting-post-boot-
video-problems] and followed every step in the guide. None of which fixed the problem.
4. I tried googling how to stop the reboot after error screen using only the BIOS menu and
couldn't find anything so I can't give a dump of the error screen as of now. The one issue I
had with this guide is that I don't have a small motherboard speaker and could not go out
and purchase one because of the time of day (stores closed by the time I got to that step).
Again, sorry about the long post, any help would be greatly appreciated. Thank you.
27 answers LAST REPLY Apr 11, 2016 BEST ANSWER Sep 15, 2012
MORE ABOUT bsod windows logo boot
1. BEST ANSWER
John_VanKirk Sep 15, 2012, 12:43 AM
Hello, & Welcome to Tom's Hardware!
Long Post!
What was your older MB? and did you have the SATA configuration set to to IDE or AHCI on
that board?
Your new ASUS P8V77 is set to AHCI by default (a change), so if the OS was set to IDE, it will
crash.
Might go into your BIOS, and on the Advanced Menu, SATA configuration, change it to IDE
mode to try.
If it boots up, then there is a registry edit so the OS it will load the AHCI drivers first.
If that's not it, you can change it back to ACHI in the BIOS.
http://www.tomshardware.co.uk/forum/320363-30-bsod-windows-logo-boot
How To Change Disk Controller Mode From IDE

to AHCI Without Reinstalling Windows
Disk controller for SATA HDDs and SSDs can operate in both AHCI and IDE compatible mode,
and usually can be reconfigured in the BIOS setup. AHCI mode is faster, has more features,
and totally makes sense for modern operating systems. Unfortunately, if you forgot to
switch from IDE to AHCI before installing Windows Vista/7/8/8.1/10, then you will get a
BSOD (blue screen of death) during the next boot, whenever you switch.
This article explains how to switch disk controller from IDE to AHCI mode after installation of
Windows, change from IDE to AHCI without reinstalling Windows.
Contents
 1. Intended audience
 2. Check prerequisites
 3. Switch from IDE mode to AHCI by
editing registry
 4. How to undo (switch back from AHCI
to IDE mode)
 5. Versions of Windows this article
applies to
1. Intended audience
This article is for users who want to switch SATA controller from IDE-compatible mode (aka
ATA-compatible mode) to AHCI mode without reinstalling Windows.
Primary motivation for such a switch is to gain additional performance from disk I/O (SATA
NCQ), especially for SSD hardware. Also recommendations from this article are useful in
dual-boot configurations, where other OS must use SATA controller in AHCI mode, and
Windows as a first OS is using SATA controller in IDE mode.
2. Check prerequisites
1. Make sure your operating system is not Windows XP. If you are using Windows XP,
then read this article.
2. Reboot your PC, enter BIOS setup (press DEL or F1) and make sure that currently
SATA controller is configured in IDE mode; and support of AHCI mode exists in BIOS.
3. Switch from IDE mode to AHCI by editing registry

1) Download Emergency Boot Kit and deploy it to USB thumbdrive. Set up your BIOS to boot
from USB thumbdrive.
2) Run Emergency Boot Kit Registry Editor.
3) Open HKEY_LOCAL_MACHINE\SYSTEM registry hive
4) Note the value of Select\Current (NNN).

5) Go to registry key ControlSetNNN\Services\msahci:
6) Set value Start=0 (it means "loaded by kernel loader").
7) Go to registry key ControlSetNNN\Services\pciide:

8) Set value Start=3 (it means "started manually"):
9) Save changed registry hive HKEY_LOCAL_MACHINE\SYSTEM to disk (F2) and exit

Emergency Boot Kit Registry Editor.
10) Choose to reboot in the main menu of Emergency Boot Kit, go to BIOS setup and switch
SATA controller to AHCI mode before Windows is loaded, otherwise you get BSoD with stop
code 0x0000007B: INACCESSIBLE_BOOT_DEVICE.
4. How to undo (switch back from AHCI to IDE mode)
1) Run Emergency Boot Kit Registry Editor.
2) Open HKEY_LOCAL_MACHINE\SYSTEM registry hive
3) Note the value of Select\Current (NNN).
4) Go to registry key ControlSetNNN\Services\pciide and set value Start=0 (it means "loaded
by kernel loader").
5) Go to registry key ControlSetNNN\Services\msahci and set value Start=3 (it means
"started manually").
6) Save changed registry hive HKEY_LOCAL_MACHINE\SYSTEM to disk (F2) and exit
Emergency Boot Kit Registry Editor.
7) Choose to reboot in the main menu of Emergency Boot Kit, go to BIOS setup and switch
SATA controller to IDE mode before Windows is loaded, otherwise you get BSoD with stop
code 0x0000007B: INACCESSIBLE_BOOT_DEVICE.
5. Versions of Windows this article applies to
This article applies to all versions of Windows after Windows XP: Windows Vista, Windows
7, Windows 8 and 8.1 and Windows 10 (both 32-bit and 64-bit editions), as well as
equivalent Windows Server operating systems.
Symbols (Whitepaper)
https://msdn.microsoft.com/en-us/library/windows/desktop/ee416588(v=vs.85).aspx
Debugging with Symbols

This article provides a high level overview of how to best use symbols in your debugging
process. It explains how to use the Microsoft symbol server, and also how to set up and use
your own private symbol server. These best practices can help increase your effectiveness
and ability to debug issues, even in cases where all the symbols and executable files that are
related to a problem are not located on your computer.
 Symbols
 Using Symbols for Debugging
 Getting the Symbols You Need
o Check if a given DLL or .exe file and PDB in the same folder match
o Check if all the DLLs and executable files in a set of folders have matching
PDBs
o How symchk Works
 Symbol Servers
 Using the Microsoft Symbol Server
 Getting Symbols Manually
 Setting Up a Symbol Server
 Adding Symbols to a Symbol Server
 Best Practices
Symbols
A number of different types of symbols are available for debugging. They include CodeView
symbols, COFF, DBG, SYM, PDB, and even export symbols that are generated from a binary
files export table. This white paper discusses only VS.NET and the PDB format symbols,
because they are the most recent, preferred format. They are generated by default for
projects that are compiled by using Visual Studio.
Generating PDB files for release executables does not affect any optimizations, or
significantly alter the size of the generated files. Typically, the only difference is the path,
and the file name of the PDB file is embedded in the executable. For this reason, you should
always produce PDB files, even if you don't want to ship them with the executable.
PDB files are generated if a project is built by using the /Zi or /ZI (Produce PDB Information)
compiler switch, together with the /DEBUG (Generate Debug Info) linker switch. The
compiler-generated PDB files are combined and written into a single PDB file that is placed
in the same directory as the executable.
By default, PDB files contain the following information:
 Public symbols (typically all functions, static and global variables)
 A list of object files that are responsible for sections of code in the executable
 Frame pointer optimization information (FPO)
 Name and type information for local variables and data structures
 Source file and line number information
If you are concerned about people using the PDB file information to help them reverse
engineer your executable, you can also generate stripped PDB files, by using
the /PDBSTRIPPED:filename linker option. If you have existing PDB files that you would like
to strip private information from, you can use a tool called pdbcopy, which is part of the
debugging tools for Windows.
By default, stripped PDB files contain the following information:
 Public symbols (typically only non-static functions and global variables)
 A list of object files that are responsible for sections of code in the executable
 Frame pointer optimization information (FPO)
This is the minimum information that is required to allow reliable debugging. Minimum
information also makes it difficult to obtain any additional information about your original
source code. Because both a stripped PDB file and a regular PDB file are generated, you can
provide the stripped version to users who may need limited debugging abilities, but keep
the full PDBs confidential. Note that /PDBSTRIPPED generates a second, smaller PDB file, so
make sure that you use the correct PDB file when you generate builds to distribute broadly.
For a typical project, a regular PDB may be a few megabytes in size, but a stripped version of
the PDB may be only a few hundred kilobytes.
Using Symbols for Debugging
When you are debugging an application that has crashed, the debugger attempts to show
you the functions on the stack that led up to the crash. Without a PDB file, the debugger can
not resolve the function names, their parameters, or any local variables that are stored on
the stack. If you debug 32-bit executables, there are situations where you cannot even get
reliable stack traces without symbols. Sometimes it's possible to look at the raw values on
the stack, and work out which values might be return addresses, but these can be easily
confused with function references or data.
If functions on the current stack were compiled by using the Omit Frame Pointers (/Oy)
optimization, and if symbols are not present, the debugger cannot reliably determine which
function called the current function. This is because without the Frame Pointer Optimization
(FPO) information that PDBs contain, the debugger cannot rely on the frame pointer register
(EBP) to point at the saved previous frame pointer and at the return address of the parent
function. Instead, it guesses. Sometimes it gets it right. However, it often gets it wrong,
which can be misleading. If you see a warning about missing symbols, or no symbols loaded,
as in the following example, do not trust the stack from that point down.
SWPerfTest.exe!TextFunction(... ...) Line 59 C++
d3dx9d.dll!008829b5()
[Frames below may be incorrect and/or missing, no symbols loaded for d3dx9d.dll]
SWPerfTest.exe!main(int argc=, const char * * argv=) Line 328 + 0x12 bytes C++
SWPerfTest.exe!__mainCRTStartup() Line 716 + 0x17 bytes C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x27 bytes
In many cases, it's possible to continue debugging without symbols, because the problem is
in a location that has accurate symbols, and you don't need to look at functions further
down the call stack. Even if a library that is in your call stack doesn't have PDBs available, as
long as they were compiled with frame pointers, the debugger should be able to guess
correctly at the parent functions. Starting with Windows XP Service Pack 2, all Windows DLL
and executable files are compiled with FPO disabled, because it makes debugging more
accurate. Disabling FPO also allows sampling profilers to walk the stack during run-time,
with minimal performance impact. On versions of Windows before Windows XP SP2, all
operating system binaries require matching symbol files that contain FPO information, to
allow accurate debugging and profiling.
If you debug 64-bit native executables, you do not need symbol files to produce valid stack
traces, because x64 operating systems and compilers are designed not to require them.
However, you still need symbol files to retrieve the function names, call parameters and
local variables.
However, some cases are particularly difficult to debug without symbols. For example, if you
debug a program for which you built a PDB file, and if you crash in a callback from a function
in a DLL that you don't have symbols for, you will not be able to see which function caused
the callback, because you will not be able to decode the stack. This frequently happens in
third-party libraries, if PDBs are not provided, or in old operating system components, if
PDBs are not available. Callbacks often happen during message passing, enumeration,
memory allocation, or exception handling. Debugging these functions without an accurate
stack can be frustrating.
To reliably debug mini-dumps that are generated on a different computer, or that crashed in
code that you do not own, it's important to be able to access all the symbols and binaries for
the executables that are referenced in the mini-dump. If the symbols and binaries are
available from a symbol server, they are automatically obtained by the debugger. For more
information on mini-dumps, see the Crash Dump Analysiswhite paper.
Getting the Symbols You Need
Visual Studio and other Microsoft debuggers, such as WinDbg, are typically set up to just
work if you are building an application and debugging it on your own computer. If you need
to give your executable to someone else, if you have multiple versions of a DLL or an .exe
file on your computer, or if you want to accurately debug an application that uses Windows
or other libraries, such as DirectX, you need to understand how debuggers find and load
symbols. The debugger uses either the symbol search path that is specified by the user—
which is found in Options\Debugging\Symbols in Visual Studio—or the _NT_SYMBOL_PATH
environment variable. Typically, the debugger searches for matching PDBs in the following
locations:
 The location that is specified inside the DLL or the executable file.
If you have built a DLL or an executable file on your computer, by default the linker places
the full path and file name of the associated PDB file inside the DLL or the executable file.
When you debug, the debugger first checks to see if the symbol file exists in the location
that is specified inside the DLL or the executable file. This is helpful, because you always
have symbols available for code that you have compiled on your computer.
 PDBs that may be present in the same folder as the DLL or executable file.
 Any local symbol cache folders.
 Any local network file share symbol servers.
 Any Internet symbol servers, such as the Microsoft symbol server.
To make sure that you have all the PDBs that you need for accurate debugging, install the
debugging tools for Windows. The 32 and 64 bit versions can be found
at http://www.microsoft.com/whdc/devtools/debugging/default.mspx.
A useful tool that is installed with this package is symchk.exe. It can help to identify missing
or incorrect symbols. This tool has a large number of potential command line options. Here
are two of the more useful and commonly used ones.
Check if a given DLL or .exe file and PDB in the same folder match
"c:\Program Files\Debugging Tools for Windows\symchk" testing.dll /s
SYMCHK: FAILED files = 0

SYMCHK: PASSED + IGNORED files = 1
The /s option tells symchk to look for symbols only in the current folder, and not to look in
any symbol servers.
Check if all the DLLs and executable files in a set of folders have matching PDBs
"c:\Program Files\Debugging Tools for Windows\symchk" *.* /r
The /r option sets symchk to recursively traverse through folders, to check that all the
executable files have matching PDBs. Without the /s option, symchk uses the current
_NT_SYMBOL_PATH to search for symbols on any private or local server, or on the Microsoft
symbol servers. The symchk tool searches only for symbols for executable files (.exe, .dll,
and similar). You cannot use wild cards search for symbols for non-executable files.
How symchk Works
When the linker generates .dll, executable, and PDB files, it stores identical GUIDs in each
file. The GUID is used by tools to determine if a given PDB file matches a DLL or an
executable file. If you alter a DLL or an executable file—by using a resource editor or copy
protection encoding, or by altering its version information—the GUID is updated and the
debugger cannot load the PDB file. For this reason, it's very important to avoid manipulating
the DLL or executable file after it is created by the linker.
You can also use the DUMPBIN utility that comes with VS.NET to show the symbol paths
that are searched, and to see if symbol files are found that match a given DLL or executable
file. For example:
DUMPBIN /PDBPATH:VERBOSE filename.exe
Symbol Servers
A symbol server is a repository for multiple versions of executable and symbol files. It
contains either the symbol files themselves, or pointers to the associated symbol files.
Debuggers understand how to use symbol servers, and can use them to search for missing
or unknown symbols.
DLL and executable files are also available from the Microsoft symbol server. This makes it
possible to debug crashes and examine code for operating system files that may not exist on
your machine. If a debugger encounters an executable file or a DLL that does not exist on
the system that you are using for debugging, it automatically requests both the symbols and
a copy of the binary file from the Microsoft symbol servers. This is helpful if you are
debugging a component that has many versions—for example, msvcrt.dll—and you need to
examine the code for a version that does not exist on your computer. This also helps debug
mini-dumps that are generated on an operating system that is different from the system
that you are using for debugging.
Microsoft publishes all the PDB files for all operating systems and other redistributed
components, such as the DirectX SDK, on its externally accessible symbol server. This makes
it easy to debug an application that uses these DLL or executable files. You can use the
Microsoft symbol server to resolve symbols, together with any local symbols for
components that were built on your computer.
You can set up your computer to use the Microsoft symbol server, which gives you access to
all Microsoft symbol files. You can also set up a private symbol server for your company,
team or network, which can be used to store multiple older versions of a project you are
working on, or to provide a local cache for the symbols that you use from the Microsoft
symbol server.
To use a symbol server, specify the search path in an environment variable that is called
_NT_SYMBOL_PATH. Debuggers and modern tools, such as WinDbg, NTSD or Visual Studio,
automatically use this path to search for symbols.
When a debugger searches for symbols, it first searches locally. Then it looks on symbol
servers. When it finds a matching symbol, it transfers the symbol file to your local cache.
The symbols for a typical DLL or executable file range from 1 to 100 MB in size. Therefore, if
you are debugging a process that includes many DLLs, it can take some time to resolve all
the symbols and transfer them to a local cache.
Using the Microsoft Symbol Server
The Microsoft symbol server allows you to obtain all the latest symbols, including symbols
for patched or updated files. The Microsoft symbol server is available
at http://msdl.microsoft.com/download/symbols.
You can access the symbol server in one of the following ways:
 Enter the server address directly. In Visual Studio, from the Tools menu,
choose Options, then choose Debugging, and then choose Symbols.
 Use the environment variable _NT_SYMBOL_PATH. We recommend this method.
This is used by all debugging tools. It is also used by Visual Studio, and is read and decoded
when Visual Studio opens. Therefore, if you change it, you need to restart Visual Studio.
This environment variable allows you to specify multiple symbol servers—for example, an
internal private symbol server. It also allows you to specify a local cache directory to store
PDBs for all symbols that you look up from symbol servers, both internally and over the
Internet.
The syntax for the _NT_SYMBOL_PATH variable is:
srv*[local cache]*[private symbol server]*https://msdl.microsoft.com/download/symbols
Replace [local cache] with the name of a directory on your computer where you want to
store a cache of any symbols used—for example, %SYSTEMROOT%\Symbols, or c:\symbols.
The [private symbol server] is optional. It can point to a symbol server that is located on
your network, or it can point to a symbol server that is shared by your team, product group,
or company.
To use only the Microsoft symbol server together with a local cache of symbols, to speed up
access over the Internet, use the following setting for _NT_SYMBOL_PATH:
srv*c:\symbols*https://msdl.microsoft.com/download/symbols
You can find other options for the _NT_SYMBOL_PATH in the help file that is installed with
the Microsoft Debugging Tools for Windows package.
Executables without symbols can increase the time it takes to launch a debugger if you use a
symbol server. This is because the debugger queries the symbol server each time it tries to
load the executable. For this reason, it is best to always request symbols for all components.
It may not be possible to request symbols for every component—for example, video drivers
may have DLLs in your process space, and the required PDB files are available on the
Microsoft symbol server. In this case, there is a small delay when you start a debugging
session.
To avoid even this small delay, you can run the debugger once, to cache all the symbols
locally from the Microsoft symbol server. Then, modify your _NT_SYMBOL_PATH to remove
the Microsoft symbol server. Unless the executable files change, checks for executable files
that do not have symbols will not require a query over the Internet, because you have local
cached copies of all the symbols that you need from the Microsoft symbol server.
Getting Symbols Manually
If you have set up your debugger correctly, it automatically loads any symbols that it
requires from your local cache or from a symbol server. If you would like to get the symbols
for just a single executable, or for a folder of executables, you can use symchk. For example,
if you want to download the symbols for the d3dx9_30.dll file in the Windows System folder
into the current directory, you can use the following command:
"c:\Program Files\Debugging Tools for Windows\symchk"
c:\Windows\System32\d3dx9_30.dll /oc \.
The symchk tool has many other uses. For details, see symchk /?, or look in the Microsoft
Debugging Tools for Windows documentation.
Setting Up a Symbol Server
Setting up a symbol server is very simple. It is useful for the following reasons:
 To save bandwidth, or to speed up symbol resolution for your company, team or
product. An internal symbol server on a local file share on your network caches any
references to external symbol servers, such as the Microsoft symbol server. A local
or internal symbol server can be accessed quickly by many people at the same time.
Therefore, it saves bandwidth and the latency that duplicate symbol requests can
create.
 To store symbols for old builds, versions or external releases of your application. By
storing the symbols for these builds on a symbol server that you can easily access,
you can debug crashes and problems in these builds on any computer that has a
debugger and a connection to the local symbol server. This is particularly useful if
you debug mini-dumps that are generated by executables that you did not build
yourself—that is, builds that were generated by another programmer or by a build
machine. If the symbols for these builds are stored on your symbol server, you will
have reliable and accurate debugging.
 To keep symbols up to date. When components are updated, such as OS
components that are modified by Windows Update or by the DirectX SDK, you can
still debug by using all the latest symbols.
Setting up a symbol server on your own local network is as simple as creating a file share on
a server and giving users full permissions to access the share, to create files and folders. This
share should be created on a server operating system, such as Windows Server 2003, so
that the number of people who can access the share simultaneously is not limited.
For example, if you set up a file share on \\mainserver\symbols, then the members of your
team set the _NT_SYMBOL_PATH to the following:
Srv*c:\symbols*\\mainserver\symbols*https://msdl.microsoft.com/download/symbols
As symbols are retrieved, files and folders appear in the \\mainserver\symbols shared
directory, as well as in individual caches, in the c:\symbols directory.
This is typically all that is involved in setting up and using either your own symbol server, or
the Microsoft symbol server.
Adding Symbols to a Symbol Server
To add, delete or edit files on a symbol server share, use the symstore.exe tool. This tool is
part of the Microsoft Debugging Tools for Windows package. Full documentation on symbol
servers, the symstore tool, and indexing symbols is included in the Debugging Tools for
Windows package.
You may want to add symbols directly to your own symbol server, as part of a build process,
or to make symbols available to your whole team for third-party libraries or tools. The
process of adding a symbol to a symbol server file share is called indexing symbols. There
are two common ways to index symbols. A symbol file can be copied to the symbol server.
Or, a pointer to the location of the symbol can be copied to the symbol server. If you have
an archive folder that contains your old builds, you may want to index pointers to the PDB
files that are already on the share, instead of duplicating symbols. Because symbols can
sometimes be tens of megabytes in size, it's a good idea to plan ahead for how much space
you may require to archive all the builds of your project throughout development. If you
index only pointers to symbols, you may have problems if you remove old builds, or change
the name of a file share.
For example, to index recursively all the symbols in c:\dxsym\Extras\Symbols that you
obtained from the October 2006 DirectX SDK onto a symbol server file share called
\\mainserver\symbols, you can use the following command:
"c:\Program Files\Debugging Tools for Windows\symstore" add /f
"C:\dxsym\Extras\Symbols\*.pdb"
/s \\mainserver\symbols /t "October 2006 DirectX SDK " /r
The /t "comment" parameter is used to add a description to the transaction that added the
symbols. This can be useful when performing administrative tasks on the symbols.
Best Practices
 Set up your own symbol server file share for your team, company, or product.
 Set up _NT_SYMBOL_PATH to point to a local cache, to a private symbol server, and
to the Microsoft symbol server.
 If a debugger cannot load symbols for a component you are debugging, contact the
owner of the component to request symbols—at least a stripped PDB.
 Set up an automated build system to index symbols on your private symbol server
for each build that is produced. Make sure that the builds that you distribute are the
builds that are generated by this process. This ensures that symbols are always
available to debug problems.
 Set up a symbol server to allow debuggers to access the source code for a specific
module directly from a Visual Source Safe or Perforce based source control system. If
the source file information and symbols for a released version of a game are
indexed, developers who have access to your symbol server can have full source
level debugging of reported issues, without keeping build environments or old
versions of source files on their development computers. To set up your symbol
server to allow indexing of source file information, see source server documentation.
Windows Perfomance Monitor

Detecting Memory bottlenecks.
Windows NT 4.0 has a virtual-memory system that combines physical memory, the file
system cache, and disk into a flexible information storage and retrieval system. The system
can store program code and data on disk until it is needed, and then move into physical
memory. Code and data no longer in active use can be written back to disk. In this way,
processes benefit from the combined space of memory and disk. But when a computer does
not have enough memory, code and data must be written to and retrieved from the disk
more frequently—a slow, resource-intensive process that can become a system bottleneck.
The best indicator of a memory bottleneck is a sustained, high rate of hard page faults. Hard
page faults occur when the data a program needs is not found in its working set (the
physical memory visible to the program) or elsewhere in physical memory, and must be
retrieved from disk. Sustained hard page fault rates—over 5 per second—are a clear
indicator of a memory bottleneck. To monitor hard fault rates and other indicators of
memory performance, log the System, Memory, Logical Disk and Process objects for several
days at an update interval of 60 seconds. Then use the following Performance Monitor
counters, described in this chapter:
Linear 32 bit memory model.
Flat memory model or linear memory model refers to a memory addressing paradigm in which
"memory appears to the program as a single contiguous address space."[1] The CPU can directly
(and linearly) address all of the available memory locations without having to resort to any sort
of memory segmentation or paging schemes.
This means that each program can see 32 bits of address space or 4 gigabytes of virtual
memory.
https://en.wikipedia.org/wiki/Flat_memory_model
The Virtual-Memory Manager in Windows NT

Randy Kath
Microsoft Developer Network Technology Group
Created: December 21, 1992
Abstract
This article provides an in-depth survey of the memory management system in Windows
NT™. Specifically, these topics are explored in detail:
 Virtual memory in Windows NT
 32-bit virtual addresses
 Page directory, page tables, and page frames
 Translating a virtual address
 Process integrity
 Reserved and committed memory
 Translation lookaside buffers
 Page-table entry structure
 Page faults
 Sharing pages across process boundaries
 Prototype page-table entries
 Copy-on-write page optimization
 Characteristics of the virtual-memory manager
 The page-frame database
 Managing a working set of pages for each process
This article does not discuss the Win32™ memory management application programming
interface (API). Instead, several other technical articles on the Microsoft Developer Network
CD should be referenced for issues related to understanding how to manage memory with
the Win32 API. Those articles provide both insight into the system and understanding of the
functions themselves. While this article primarily deals with Windows NT-specific memory
management issues, it does refer to some of the memory objects in the Win32 subsystem
(like memory-mapped files and dynamic heaps) in an attempt to shed some light on the age-
old dilemma of performance vs. resource usage as it applies to applications written for the
Win32 subsystem in Windows NT.
Introduction
As the size of applications and the operating systems that run them grow larger and larger,
so do their demands on memory. Consequently, all modern operating systems provide a
form of virtual memory to applications. Being the newest of the operating systems to hit the
main stream, Windows NT™ will likely have applications ported to it that will evolve into
larger monstrosities that require even more memory than they did on the last operating
system on which they ran. Even applications being written exclusively for Windows NT will
be written with the future in mind and will no doubt take advantage of all the memory that
is available to them.
Fortunately, Windows NT does, in fact, offer virtual memory to its applications (or
processes) and subsystems. Windows NT provides a page-based virtual memory
management scheme that allows applications to realize a 32-bit linear address space for 4
gigabytes (GB) of memory. As a result, each application has its own private address space
from which it can use the lower 2 GB—the system reserves the upper 2 GB of every
process's address space for its own use.
Private address space
Figure 1. A process in Windows NT has a 4-GB linear address space, of which the lower 2
GB is available for applications to use.
As illustrated in Figure 1, each process can address up to 4 GB of memory using 32-bit linear
addresses. The upper half of the address space is reserved for use by the system. Because
the system is the same for each process, regardless of the subsystem it runs on, similar
pages of system memory are typically mapped to each process in the same relative location
for efficiency.
Note The Win32™ subsystem provides user services that are loaded as dynamic-link
libraries (DLLs) into the lower portion of the address space of a process. These DLLs exist in
addition to the system DLLs that occupy the upper portion of the address space. Depending
on which DLLs an application links or loads, the DLLs that are mapped into the lower portion
of a process's address space will vary from one application to the next within a subsystem.
If only we had PCs with similar memory capacities. . . . Actually, a computer doesn't really
need 4 GB of physical memory for Windows NT to operate effectively—though the general
rule of virtual memory systems is the more physical memory, the better the performance.
Windows NT's memory management system virtualizes memory such that to each
application it appears as though there is 2 GB of memory available, regardless of how much
physical memory actually exists. In order to do this, Windows NT must manage memory in
the background without regard to the instantaneous requests that each application makes.
In fact, the memory manager in Windows NT is a completely independent process consisting
of several threads that constantly manage available resources.
Windows version 3.x has realizable limitations to the maximum amount of memory
available to it and all of its applications; these are often barriers to large applications for this
environment. Windows NT's limits are far more theoretical. Windows NT employs the PC's
hard disk as the memory-backing store and, as such, has a practical limit imposed only by
available disk space. So, it is reasonable to assume that a Windows NT system could have an
extremely large hard disk or array of disks amounting to 2 GB or more of physical memory
and provide that much virtual memory to each of its applications (minus the portions used
by the system, occupied by the file system, and allocated by files stored within the file
system). In short, Windows NT provides a seemingly endless supply of memory to all of the
applications running on it.
Virtual Memory in Windows NT
The virtual-memory manager (VMM) in Windows NT is nothing like the memory managers
used in previous versions of the Windows operating system. Relying on a 32-bit address
model, Windows NT is able to drop the segmented architecture of previous versions of
Windows. Instead, the VMM employs 32-bit virtual addresses for directly manipulating the
entire 4-GB process. At first this appears to be a restriction because, without segment
selectors for relative addressing, there is no way to move a chunk of memory without
having to change the address that references it. In reality, the VMM is able to do exactly
that by implementing virtual addresses. Each application is able to reference a physical
chunk of memory, at a specific virtual address, throughout the life of the application. The
VMM takes care of whether the memory should be moved to a new location or swapped to
disk completely independently of the application, much like updating a selector entry in the
local descriptor table (LDT)
Windows versions 3.1 and earlier employed a scheme for moving segments of memory to
other locations in memory both to maximize the amount of available contiguous memory
and to place executable segments in the location where they could be executed. An
equivalent operation is unnecessary in Windows NT's virtual memory management system
for three reasons. One, code segments are no longer required to reside in the 0-640K range
of memory in order for Windows NT to execute them. Windows NT does require that the
hardware have at least a 32-bit address bus, so it is able to address all of physical memory,
regardless of location. Two, the VMM virtualizes the address space such that two processes
can use the same virtual address to refer to distinct locations in physical memory. Virtual
address locations are not a commodity, especially considering that a process has 2 GB
available for the application. So, each process may use any or all of its virtual addresses
without regard to other processes in the system. Three, contiguous virtual memory in
Windows NT can be allocated discontiguously in physical memory. So, there is no need to
move chunks to make room for a large allocation.
The foundation for the system provides the answer to how VMM is able to perform these
seemingly miraculous functions. VMM is constructed upon a page-based memory
management scheme that divides all of memory into equal chunks called pages. Each page
is 4096 bytes (4K) in size with no discrimination applied as to how a page is used. Everything
in Windows NT—code, data, resources, files, dynamic memory, and so forth—is
implemented using pages of physical memory.
The foundation for the system provides the answer to how VMM is able to perform these
seemingly miraculous functions. VMM is constructed upon a page-based memory
management scheme that divides all of memory into equal chunks called pages. Each page
is 4096 bytes (4K) in size with no discrimination applied as to how a page is used. Everything
in Windows NT—code, data, resources, files, dynamic memory, and so forth—is
implemented using pages of physical memory.
Because everything in the system is realized via pages of physical memory, it is easy to see
that pages of memory become scarce rather quickly. VMM employs the use of the hard disk
to store unneeded pages of memory in one or more files called pagefiles. Pagefiles
represent pages of data that are not currently being used, but may be needed
spontaneously at any time. By swapping pages to and from pagefiles, the VMM is able to
make pages of memory available to applications on demand and provide much more virtual
memory than the available physical memory. Also, pagefiles in Windows NT are dynamic in
size, allowing them to grow as the demands for pages of memory grow. In this way,
Windows NT is able to provide virtually unlimited memory to the system.
Note A detailed discussion on how the virtual-memory manager performs the functions
mentioned here is presented later in this article in the section "The Virtual-Memory
Manager (VMM)."
32-Bit Virtual Addresses
One of the conveniences of the 32-bit linear address space is its continuity. Applications are
free to use basic arithmetic on pointers based on 32-bit unsigned integers, which makes
manipulating memory in the address space relatively easy. Though this is how addresses are
viewed by an application, Windows NT translates addresses in a slightly different manner.
To Windows NT, the 32-bit virtual address is nothing more than a placeholder of
information used to find the actual physical address. Windows NT separates each 32-bit Commented [A1]: offset
virtual address into three groups. Each group of bits is then used independently as an offset noun
noun: offset; plural noun: offsets; noun: off-set; plural
into a specific page of memory. Figure 2 shows how the 32-bit virtual address is divided into noun: off-sets
three offsets, two containing 10 bits and one containing 12.
ˈɒfsɛt/
1.1.
a consideration or amount that diminishes or balances the
effect of an opposite one.
Figure 2. A 32-bit virtual address in Windows NT is divided into page offsets that are used "widow's bereavement allowance is an offset against income"
2.2.
for translating the address into a physical location in memory. the amount or distance by which something is out of line.
Offset meaning "these wheels have an offset of four inches"
oSURVEYING
In computing terms: a short distance measured perpendicularly from the main line
of measurement.
Offset (computer science) "if it was a simple curve, he was taught the ‘ranging by offsets’
technique"
From Wikipedia, the free encyclopedia oELECTRONICS
a small deviation or bias in a voltage or current.
"offset adjustment circuits"
This article does not cite any sources. Please help improve this 3.3.
article by adding citations to reliable sources. Unsourced material a side shoot from a plant serving for propagation.
"a present of tulip bulbs, offsets, and seeds for his garden"
may be challenged and removed. (October 2015) (Learn how and oa spur in a mountain range.
when to remove this template message) 4.4.
ARCHITECTURE
a sloping ledge in a wall or other feature where the thickness
In computer science, an offset within an array or other data structure object is of the part above is diminished.
5.5.
an integer indicating the distance (displacement) between the beginning of the object and a a bend in a pipe to carry it past an obstacle.
given element or point, presumably within the same object. The concept of a distance is "allow for any bend you need including offsets for connecting
the downpipe"
valid only if all elements of the object are of the same size (typically given 6.6.
in bytes or words). a method of printing in which ink is transferred from a plate or
stone to a uniform rubber surface and from that to the paper.
For example, in A as an array of characters containing "abcdef", the fourth element "they produced banknotes by offset"
containing the character 'd' has an offset of three from the start of A.
Commented [A2]: a set of items each of which specifies
Index in computing one of the records of a file and contains information about its
address.
Index
(in a book or set of books) an alphabetical list of names,
An index is a list of data, such as group of filesor database entries. It is typically saved in subjects, etc. with reference to the pages on which they are
a plain text format that can be quickly scanned by a search algorithm. This significantly mentioned.
"clear cross references supplemented by a thorough index"
speeds up searching and sorting operations on data referenced by the index. Indexes often an alphabetical list by title, author, or other category of a
collection of books or documents, for example in a library.
synonyms: ...
include information about each item in the list, such as metadata or keywords, that allows
the data to be searched via the index instead of reading through each file individually.
For example, a database program such as Microsoft Access may generate an index of entries
in a table. When an SQL query is run on the database, the program can quickly scan the
index file to see what entries match the search string. Search engines also use indexes to
store a large list of Web pages. These indexes, such as those created by Google and Yahoo!,
are necessary for quickly generating search results. If search engines had to scan through
millions of pages each time a user submitted a search, it would take roughly forever.
Fortunately, by using search indexes, Web searches can be performed in less than a second
instead of several hours.
The term "index" can also be used as a verb, which not surprisingly means to create an
index. It may also refer to adding a new item to an existing index. For example, Mac OS X
10.4 and later indexes the hard disk to create a searchable index for Apple's Spotlight search
utility. Google's "Googlebot" crawls the Web on a regular basis, adding new Web pages to
the Google index. While most database and hard disk indexes are updated on-the-fly, search
engine indexes are only updated every few hours, days, or even weeks. This is why newly
published Web pages may not show up in search engine results. While it may be a
frustration for Web developers, it is a small price to pay for the convenience of super-fast
Web searches.
In computing, the most significant bit (MSB, also called the high-order bit) is the bitposition
in a binary number having the greatest value. The MSB is sometimes referred to as the left-
most bit due to the convention in positional notation of writing more significant digits
further to the left
Page Directory, Page Tables, and Page Frames
The first step in translating the virtual address is to extract the higher-order 10 bits to serve
as the first offset. This offset is used to index a 4-byte value in a page of memory called
the page directory. Each process has a single, unique page directory in the Win32
subsystem. The page directory is itself a 4K page, segmented into 1024 4-byte values
called page-directory entries (PDEs). The 10 bits provide the exact number of bits necessary
to index each PDE in the page directory (210 bits = 1024 possible combinations).
Each PDE is then used to identify another page of memory called a page table. The second
10-bit offset is subsequently used to index a 4-byte page-table entry (PTE) in exactly the
same way as the page directory does. PTEs identify pages of memory called page frames.
The remaining 12-bit offset in the virtual address is used to address a specific byte of
memory in the page frame identified by the PTE. With 12 bits, the final offset can index all
4096 bytes in the page frame.
Through three layers of indirection, Windows NT is able to offer virtual memory that is
unique to each process and relatively independent of available physical resources. Also,
embedded within this structure is the basis for managing all of memory based on 4K pages.
Every page in the system can be categorized as either a page directory, page table, or page
frame.
Realizing 4 GB of Address Space
Translating a virtual address from page directory to page frame is similar to traversing a b-
tree structure, where the page directory is the root; page tables are the immediate
descendants of the root; and page frames are the page table's descendants. Figure 3
illustrates this organization.
Figure 3. Translating a virtual address is similar to traversing a b-tree structure.

A page directory has up to 1024 PDEs or a maximum of 1024 page tables. Each page table
contains up to 1024 PTEs with a maximum of 1024 page frames per page table. Each page
frame has its own 4096 one-byte locations of actual data. All totaled, the 32-bit virtual
address can be translated into 4 GB of address space (1024 * 1024 * 4096). Yet, there is still
the question of the pages that are used to represent the page tables and page directory.
Looking closely at Figure 3 reveals that a considerable amount of overhead is required to
completely realize all of the page frames in memory. In fact, to address each location in the
4-GB address space would require one page directory and 1024 page tables. Because each
page is 4K of memory, 4 MB (approximately) of memory would be needed just to represent
the address space ( [1024 page tables + 1 page directory] * 4096 bytes/page).
Although that may seem like a high price to pay, it really isn't, for two reasons: First, 4 MB is
less than 0.1 percent of the entire 4-GB address space, which is a reasonably small amount
of overhead when you consider comparable operating systems. Second, Windows NT
realizes the address space as it is needed by the application, rather than all at once, so page
tables are not created until the addresses they are used to translate are needed.
In the x86 architecture, page directories and page tables together provide the mapping
between virtual addresses (memory addresses used by applications) and physical addresses
(actual locations in the physical memory hardware).
A page is simply a contiguous chunk of memory. x86 (32-bit) supports 3 sizes of pages: 4MB,
2MB, and 4KB, with the latter being the most commonly used in mainstream operating
systems. A page table is an array of 1024 * 32-bit entries (conveniently fitting into a single
4KB page). Each entry points to the physical address of a page. Because a single page table is
not able to represent the entire address space on its own (1024 entries * 4KB = only 22-bits
of address space), we require a second level page table: a page directory. A page directory
also consists of 1024 * 32-bit entries (again fitting into a single page), each pointing to a
page table. We can see that now 1024 * 1024 * 4KB = 32-bits and with this 3-level structure
we are able to map the entire 4GB virtual address space.
When the CPU is asked to access a virtual address, it uses the 10 highest order bits (31:22)
to index into the page directory table (the base address of which is stored in a special
register). The next 10 highest order bits (21:12) are used to index into the page table
pointed to by the page directory entry. The lowest 12 order bits (11:0) are finally used to
index a byte in the page pointed to by the page table entry.
In other systems there may be more or fewer levels of page table required, depending on
the size of the virtual address space and the page sizes supported. For example, x86 with
4MB pages only needs a single page directory. In 64-bit mode with 4KB pages, a 4-level
system is used: a page mapping level 4 table contains entries that point to one of many
page directories.
https://support.microsoft.com/en-in/help/2160852/ram--virtual-memory--pagefile--
and-memory-management-in-windows
Processes and address spaces
All processes (for example, application executables) that are running under 32-bit
versions of Windows are assigned virtual memory addresses (a virtual address space),
ranging from 0 to 4,294,967,295 (2*32-1 = 4 GB), regardless of how much RAM is
actually installed on the computer.
In the default Windows configuration, 2 gigabytes (GB) of this virtual address space are
designated for the private use of each process, and the other 2 GB is shared between all
processes and the operating system. Typically, applications (for example, Notepad, Word,
Excel, and Acrobat Reader) use only a fraction of the 2 GB of private address space. The
operating system assigns RAM page frames only to those virtual memory pages that are
being used.
Physical Address Extension (PAE) is the feature of the Intel 32-bit architecture that
expands the physical memory (RAM) address to 36 bits. PAE does not change the size of
the virtual address space (which remains at 4 GB), but just the volume of actual RAM that
can be addressed by the processor. For more information, click the following article
number to view the article in the Microsoft Knowledge Base:
The translation between the 32-bit virtual memory address that is used by the code that
is running in a process and the 36-bit RAM address is handled automatically and
transparently by the computer hardware according to translation tables that are
maintained by the operating system. Any virtual memory page (32-bit address) can be
associated with any physical RAM page (36-bit address)
Pagefile
RAM is a limited resource, whereas for most practical purposes, virtual memory is
unlimited. There can be many processes, and each process has its own 2 GB of private
virtual address space. When the memory being used by all the existing processes
exceeds the available RAM, the operating system moves pages (4-KB pieces) of one or
more virtual address spaces to the computer’s hard disk. This frees that RAM frame for
other uses. In Windows systems, these “paged out” pages are stored in one or more files
(Pagefile.sys files) in the root of a partition. There can be one such file in each disk
partition. The location and size of the page file is configured in System
Properties (click Advanced, click Performance, and then click the Settings button).
Users frequently ask "how big should I make the pagefile?" There is no single answer to
this question because it depends on the amount of installed RAM and on how much
virtual memory that workload requires. If there is no other information available, the
typical recommendation of 1.5 times the installed RAM is a good starting point. On
server systems, you typically want to have sufficient RAM so that there is never a
shortage and so that the pagefile is basically not used. On these systems, it may serve no
useful purpose to maintain a really large pagefile. On the other hand, if disk space is
plentiful, maintaining a large pagefile (for example, 1.5 times the installed RAM) does not
cause a problem, and this also eliminates the need to worry over how large to make it.
Performance, architectural limits, and RAM
On any computer system, as the load increases (the number of users, the volume of
work), performance decreases, but in a nonlinear manner. Any increase in load or
demand, beyond a certain point, causes a significant decrease in performance. This
means that some resource is in critically short supply and has become a bottleneck.
At some point, the resource that is in short supply cannot be increased. This means that
an architectural limit has been reached. Some frequently reported architectural limits in
Windows include the following:
 2 GB of shared virtual address space for the system (kernel)
 2 GB of private virtual address space per process (user mode)
 660 MB of system PTE storage (Windows Server 2003 and earlier)
 470 MB of paged pool storage (Windows Server 2003 and earlier)
 256 MB of nonpaged pool storage (Windows Server 2003 and earlier)
 This applies to Windows Server 2003 specifically, but this may also apply to
Windows XP and to Windows 2000. However, Windows Vista, Windows Server
2008, and Windows 7 do not all share these architectural limits. The limits on user
and kernel memory (numbers 1 and 2 here) are the same, but kernel resources
such as PTEs and various memory pools are dynamic. This new functionality
enables both paged and nonpaged memory. This also enables PTEs and session
pool to grow beyond the limits that were discussed earlier, up to the point where
the whole kernel is exhausted.
Frequently found and quoted statements such as the following:

 With a Terminal Server, the 2 GB of shared address space will be completely used
before 4 GB of RAM is used.”
 This may be true in some cases. However, you have to monitor your system to
know whether they apply to your particular system or not. In some cases, these
statements are conclusions from specific Windows NT 4.0 or Windows 2000
environments and do not necessarily apply to Windows Server 2003. Significant
changes were made to Windows Server 2003 to reduce the probability that these
architectural limits will in fact be reached in practice. For example, some
processes that were in the kernel were moved to non-kernel processes to reduce
the memory used in the shared virtual address space.
 Comparison of 32-bit and 64-bit

memory architecture for 64-bit
editions of Windows XP and
Windows Server 2003

 Summary

 In the following table, the increased maximum resources of computers that are based
on 64-bit versions of Windows and the 64-bit Intel processor are compared with
existing 32-bit resource maximums.
Architectural component 64-bit Windows 32-bit Windows
Virtual memory 16 terabytes 4 GB
Paging file size 256 terabytes 16 terabytes
Hyperspace 8 GB 4 MB
Paged pool 128 GB 470 MB
Non-paged pool 128 GB 256 MB

System cache 1 terabyte 1 GB
System PTEs 128 GB 660 MB
 More Information

 Virtual memory
 This is a method of extending the available physical memory on a computer.
In a virtual memory system, the operating system creates a pagefile, or swapfile, and
divides memory into units called pages. Recently referenced pages are located in
physical memory, or RAM.
If a page of memory is not referenced for a while, it is written to the pagefile. This is
called "swapping" or "paging out" memory. If that piece of memory is then later
referenced by a program, the operating system reads the memory page back from
the pagefile into physical memory, also called "swapping" or "paging in" memory.
The total amount of memory that is available to programs is the amount of physical
memory in the computer in addition to the size of the pagefile. An important
consideration in the short term is that even 32-bit applications will benefit from
increased virtual memory address space when they are running in Windows x64
Editions.
Applications that are compiled with the /LARGEADDRESSAWARE option, as would be

required to take advantage of the /3GB switch in 32-bit Windows, will automatically
be able to address 4 GB of virtual memory without any boot time switches or
changes to x64 Windows. Plus, of course, the operating system does not have to
share that 4 GB of space. Therefore, it is not constrained at all.
 Paging file
 This is a disk file that the computer uses to increase the amount of physical storage
for virtual memory.
 Hyperspace
 This is a special region that is used to map the process working set list and to
temporarily map other physical pages for such operations as zeroing a page on the
free list (when the zero list is empty and the zero page is needed), invalidating page
table entries in other page tables (such as when a page is removed from the standby
list), and in regards to process creation, setting up the address space of a new
process.
 Paged pool
 This is a region of virtual memory in system space that can be paged in and out of
the working set of the system process. Paged pool is created during system
initialization and is used by Kernel-mode components to allocate system memory.
Uniproccessor systems have two paged pools, and multiprocessor systems have four.
Having more than one paged pool reduces the frequency of system code blocking
on simultaneous calls to pool routines.
 Non-paged pool
 This is a memory pool that consists of ranges of system virtual addresses that are
guaranteed to be resident in physical memory at all times and thus can be accessed
from any address space without incurring paging input/output (I/O). Non-paged
pool is created during system initialization and is used by Kernel-mode components
to allocate system memory.
 System cache
 These are pages that are used to map open files in the system cache.
 System PTEs
 A pool of system Page Table Entries (PTEs) that is used to map system pages such as
I/O space, Kernel stacks, and memory descriptor lists. 64-bit programs use a 16-
terabyte tuning model (8 terabytes User and 8 terabytes Kernel). 32-bit programs still
use the 4-GB tuning model (2 GB User and 2 GB Kernel). This means that 32-bit
processes that run on 64-bit versions of Windows run in a 4-GB tuning model (2 GB
User and 2GB Kernel). 64-bit versions of Windows do not support the use of
the /3GB switch in the boot options. Theoretically, a 64-bit pointer could address up
to 16 exabytes. 64-bit versions of Windows have currently implemented up to 16
terabytes of address space.
https://support.microsoft.com/en-us/help/294418/comparison-of-32-bit-and-64-bit-
memory-architecture-for-64-bit-edition
Working Set
The working set of a process is the set of pages in the virtual address space of the process
that are currently resident in physical memory. The working set contains only pageable
memory allocations; nonpageable memory allocations such as Address Windowing
Extensions(AWE) or large page allocations are not included in the working set.
When a process references pageable memory that is not currently in its working set, a page
fault occurs. The system page fault handler attempts to resolve the page fault and, if it
succeeds, the page is added to the working set. (Accessing AWE or large page allocations
never causes a page fault, because these allocations are not pageable .)
A hard page fault must be resolved by reading page contents from the page's backing store,
which is either the system paging file or a memory-mapped file created by the process.
A soft page fault can be resolved without accessing the backing store. A soft page fault
occurs when:
 The page is in the working set of some other process, so it is already resident in
memory.
 The page is in transition, because it either has been removed from the working sets
of all processes that were using the page and has not yet been repurposed, or it is
already resident as a result of a memory manager prefetch operation.
 A process references an allocated virtual page for the first time (sometimes called
a demand-zero fault).
Pages can be removed from a process working set as a result of the following actions:
 The process reduces or empties the working set by calling
the SetProcessWorkingSetSize, SetProcessWorkingSetSizeEx or EmptyWorkingSet f
unction.
 The process calls the VirtualUnlock function on a memory range that is not locked.
 The process unmaps a mapped view of a file using the UnmapViewOfFile function.
 The memory manager trims pages from the working set to create more available
memory.
 The memory manager must remove a page from the working set to make room for a
new page (for example, because the working set is at its maximum size).
If several processes share a page, removing the page from the working set of one process
does not affect other processes. After a page is removed from the working sets of all
processes that were using it, the page becomes a transition page. Transition pages remain
cached in RAM until the page is either referenced again by some process or repurposed (for
example, filled with zeros and given to another process). If a transition page has been
modified since it was last written to disk (that is, if the page is "dirty"), then the page must
be written to its backing store before it can be repurposed. The system may start writing
dirty transition pages to their backing store as soon as such pages become available.
Each process has a minimum and maximum working set size that affect the virtual memory
paging behavior of the process. To obtain the current size of the working set of a specified
process, use the GetProcessMemoryInfo function. To obtain or change the minimum and
maximum working set sizes, use
the GetProcessWorkingSetSizeEx and SetProcessWorkingSetSizeEx functions.
The process status application programming interface (PSAPI) provides a number of
functions that return detailed information about the working set of a process. For details,
see Working Set Information.
4.3. Paged Memory Management
 A page is a unit of logical memory of a program
 A frame is a unit of physical memory
 All pages are of the same size
 All frames are of the same size
 A frame is of the same size as a page
4.3.1. Using the Page Table
 To produce a physical address, you first look up the page in the PMT to find the
frame number in which it is stored. Then multiply the frame number by the frame
size and add the offset to get the physical address.
 A page table is kept in main memory. It is part of the process control block (PCB) for
each process.
 Page-table base register (PTBR) points to the page table.
 Page-table length register (PRLR) indicates size of the page table.
 In this scheme every data/instruction access requires two memory accesses. One for
the page table and one for the data/instruction.
4.3.2. Windows PMT
4.3.3. Linux PMT
https://www.d.umn.edu/~gshute/os/address-translation.xhtml
Virtual Memory Address Translation

In a system with virtual memory the main memory can be viewed as a cache for the disk,
which serves as the lower-level store. Due to the enormous difference between memory
access times and disk access times, a fully-associative caching scheme is used. That is, the
entire main memory is a single set - any page can be placed anywhere in main memory. This
makes the set field of the address vanish. All that remains is a tag and an offset.
 The offset field identifies a particular location within page or frame.
 The tag field identifies a page in the logical address space.
Since the tag field just identifies a page it is usually called the page number field.
Logical Addresses
With a virtual memory system, the main memory can be viewed as a local store for a cache
level whose lower level is a disk. Since it is fully associative there is no need for a set field.
The address just decomposes into an offset field and a page number field. The number of
bits in the offset field is determined by the page size. The remaining bits are the page
number.
An Example
A computer uses 32-bit byte addressing. The computer uses paged virtual memory with 4KB
pages. Calculate the number of bits in the page number and offset fields of a logical address.
Answer
Since there are 4K bytes in a cache block, the offset field must contain 12 bits (212 = 4K). The
remaining 20 bits are page number bits.
Thus a logical address is decomposed as shown below.
20 12
page
offset
number
Working Set
The working set of a process is the set of pages in the virtual address space of the process that
are currently resident in physical memory. The working set contains only pageable memory
allocations; nonpageable memory allocations such as Address Windowing Extensions(AWE)
or large page allocations are not included in the working set.
When a process references pageable memory that is not currently in its working set, a page
fault occurs. The system page fault handler attempts to resolve the page fault and, if it succeeds,
the page is added to the working set. (Accessing AWE or large page allocations never causes a
page fault, because these allocations are not pageable .)
A hard page fault must be resolved by reading page contents from the page's backing store,
which is either the system paging file or a memory-mapped file created by the process. A soft
page fault can be resolved without accessing the backing store. A soft page fault occurs when:
 The page is in the working set of some other process, so it is already resident in memory.
 The page is in transition, because it either has been removed from the working sets of all
processes that were using the page and has not yet been repurposed, or it is already resident as
a result of a memory manager prefetch operation.
 A process references an allocated virtual page for the first time (sometimes called a demand-zero
fault).
Pages can be removed from a process working set as a result of the following actions:
 The process reduces or empties the working set by calling
the SetProcessWorkingSetSize, SetProcessWorkingSetSizeEx or EmptyWorkingSet function.
 The process calls the VirtualUnlock function on a memory range that is not locked.
 The process unmaps a mapped view of a file using the UnmapViewOfFile function.
 The memory manager trims pages from the working set to create more available memory.
 The memory manager must remove a page from the working set to make room for a new page
(for example, because the working set is at its maximum size).
If several processes share a page, removing the page from the working set of one process does
not affect other processes. After a page is removed from the working sets of all processes that
were using it, the page becomes a transition page. Transition pages remain cached in RAM until
the page is either referenced again by some process or repurposed (for example, filled with zeros
and given to another process). If a transition page has been modified since it was last written to
disk (that is, if the page is "dirty"), then the page must be written to its backing store before it can
be repurposed. The system may start writing dirty transition pages to their backing store as soon
as such pages become available.
Each process has a minimum and maximum working set size that affect the virtual memory
paging behavior of the process. To obtain the current size of the working set of a specified
process, use the GetProcessMemoryInfo function. To obtain or change the minimum and
maximum working set sizes, use
the GetProcessWorkingSetSizeEx and SetProcessWorkingSetSizeEx functions.
The process status application programming interface (PSAPI) provides a number of functions
that return detailed information about the working set of a process. For details, see Working Set
Information.
Process Working Set

The working set of a program is a collection of those pages in its virtual address space that have
been recently referenced. It includes both shared and private data. The shared data includes
pages that contain all instructions your application executes, including those in your DLLs and the
system DLLs. As the working set size increases, memory demand increases.
A process has an associated minimum working set size and maximum working set size. Each time
you call CreateProcess, it reserves the minimum working set size for the process. The virtual
memory manager attempts to keep enough memory for the minimum working set resident when
the process is active, but keeps no more than the maximum size.
To get the requested minimum and maximum sizes of the working set for your application, call
the GetProcessWorkingSetSize function.
The system sets the default working set sizes. You can also modify the working set sizes using
the SetProcessWorkingSetSize function. Setting these values is not a guarantee that the memory
will be reserved or resident. Be careful about requesting too large a minimum or maximum
working set size, because doing so can degrade system performance.
To obtain the current or peak size of the working set for your process, use
the GetProcessMemoryInfo function.
Related topics
Memory Performance Information
Working Set
Ask the Directory Services Team
Microsoft's official enterprise support blog for AD DS and more
Mythical Creatures – Corrupt User Profiles
★★★★★
★★★★
★★★
★★
★
October 20, 2010 by MikeStephensMSFT // 12 Comments

 0
 0
“Ned” the Gnome

Mike here again and in the spirit of Halloween I want to discuss mythical creatures. What
would the world be without J.R.R. Tolkien’s idea of smelly, leather-skinned Orcs or Greek
Mythology’s gift of Pegasus, the winged stallion? Unfortunately, for each great mythical
creature, like giant walking trees (that walk for hours—thank you Kevin Smith), there is a
horrendous one. The dreadful creature I want to discuss today is the corrupt user profile.
I absolutely shudder when I hear the words “corrupt profile.” Like Superman, who is
defeated by a glowing green rock—the corrupt profile is my kryptonite (Ned’s is the
phrase Tips and Tricks). So, the purpose of this blog is to dispel the myth of the corrupt user
profile.
Let me start by contradicting myself—there is actually such a thing as a corrupt user profile;
however, it is extremely rare. I’ve spent over ten years at Microsoft and I’ve seen two—
count them—two actually corrupt user profiles. I’ll identify the “real” corrupt profile later.
First, let’s identify what is NOT a corrupt user profile because it’s more prevalent.
User profile load failure
Occasionally, users report their profiles not loading, or Windows informs users that it logged
the user on with a temporary user profile. It’s rare for Windows to not load a user profile
because it is a “corrupt” user profile. Typically, a user profile does not load because:
 A process is not playing nice in the sandbox—meaning some process other than
Winlogon opened ntuser.dat exclusively thereby preventing Winlogon from loading
the user profile.
 Windows cannot find the user profile. This is most often the case when using
Roaming, Mandatory, or Super Mandatory user profiles. All these profile types
require network connectivity. In these cases, no network means Windows will not
loaded user profile.
 Configuration – Windows is configured, through a policy or otherwise, not to load
the user profile. Profile quota size, or slow links are common causes for this scenario.
The most common scenario classified as the mythical corrupt profile is the first, and rightly
so because is painfully difficult to diagnose. Configuration is the second most likely scenario
that attributes to the mythical corrupt profile. It’s rare to associate unavailable user profiles
as corrupt, or scenarios involving the awesome access is denied error message.
User settings missing
Another scenario that perpetuates the corrupted profile myth is one that involves user
settings disappearing. It’s unlikely that user settings disappear; it’s more likely the user
settings were not saved. A number of scenarios can lead to this possibility.
Profile trickery
Most recently, I’ve seen a number of scenarios, mostly with Terminal Servers, where
settings do not persist. Our case data show a trend of these scenarios using non-Microsoft
profile management software. This software changes how Windows handles the user
profile. Typically, these implementations treat the user profile as a local profile and then
implements “magical magic” to roam user data back to a central location. This introduces a
number of moving parts that must work correctly to ensure user settings are saved. Also,
some of these non-Microsoft solutions allow you to partition portions of the user settings
that persistent and those that do not. This allows control over which user settings roam
through their solution and which settings do not. In these cases, verify the solution, third-
party or otherwise, propagated the saved settings. However, this is not a corrupt user
profile.
Multiple instances – last writer wins
Remember that Windows stores user settings in a registry file. The registry file is the
smallest unit of roaming data. That means that Windows roams the entire user hive when
the user logs off (or in the background with Windows 7). However, when a user logs on to
multiple computers or has multiple sessions, then that user’s settings are only as good as
the last session that writes to the central location.
Consider the following scenario. A user has a laptop and frequently uses Terminal Services.
The user shares the same profile between these computers. On Friday, the user logs on
their laptop—the profile is loaded. After some time, the user makes a Terminal Services
connection and begins to work in that session. The user then disconnects the Terminal
Services session and goes to lunch. When they return, they change their desktop
background on their laptop. The user logs off at the end of the day and their saved user
settings roam to the central location. On Monday, the user logs on expecting their new
desktop background; however, they receive their old desktop background. You discover that
idle Terminal Services sessions are configured to logoff after a preconfigured idle time. The
session’s user settings have a later time stamp then the previous and therefore writes last,
resulting in the user’s setting appearing as if they did not save. This is another reason why
we encourageseparate user profiles for Terminal Services. So, add this experience to the list
of mythical corrupt profiles.
Misbehaving applications
Another scenario that perpetuates the corrupt profile myth is with misbehaving applications
that “magically” work when you delete the user profile. This is not a corrupt user profile.
There is a big different between corrupt data and unexpected data. It’s difficult to
determine what is wrong in these scenarios.
Clearly it is related to user data because resetting the user data to blank or nothing restores
the application’s performance to the expected behavior. These scenarios require a thorough
understanding of the application, how it consumes user data, and the upper and lower
limits of each setting. Deleting the entire user profile to accommodate a misbehaving
application is a quick fix with huge ramifications. The “fix” for one application effectively
breaks other applications. Also, deleting the user profile removes stored credentials, keys,
and certificates that may be critical to the user.
A better approach is to create a new user and test the application with a new user profile.
But deleting a user profile because an application or a feature of an application does not
work is overlooking the larger issue. Resist the urge and instead break out Process Monitor,
capture registry activity, and reproduce the issue. Inventory the registry keys the
applications uses in the user’s hive. Review the values of each of the keys in a working and
failing scenario and compare the two. Use the process of elimination to determine the
setting and value that is causing the failure.
If time is not on your side and you know deleting the user profile resolves the problem,
then create a virtual machine of the problematic computer so you can continue your
investigation at a later time. Incorrect data stored in user settings does not make the profile
corrupt.
Will the real corrupt profile please stand up
I’ve identified some of the common misconceptions that are associated with the corrupt
profile mythology, and there are others. However, these scenarios consistently rise to the
top. So, what is a real corrupt profile? I’m glad you asked.
A user profile is a predetermined folder structure and accompanying registry data. Microsoft
Windows uses the registry data to describe and preserve the user environment. The folder
structure is storage for user and application data, specifically for an individual user.
Windows stores the profile on the local hard drive, loads the profile when the user logs on,
and unloads the profile when the user logs off.
The preserved data that describes the user’s environment is nothing more than a registry
hive. More specifically, the user’s registry portion of the profile is loaded into
HKEY_CURRENT_USER. Registry hives, keys, value names, and values are stored in a specific
structure that Windows recognizes as the registry. Each element within the structure has its
own metadata, such as last write time and security descriptor. All of this information must
adhere to the scope and limits of the structure. Consider the following example:
An application saves the position of its window in the user’s settings. Window locations are
represented as coordinates on the screen. These coordinates are integer values. Integers
are positive or negative values. However, the upper left corner of the screen is typically
represented by the coordinate 0, 0. What if another application saved -12 and 0 as this
data? Both numbers are valid integers. It meets the structure of a REG_DWORD, which is an
integer data type for the registry. Yet, the application does not work correctly when this
value is present in the registry. This is not a corrupt profile—its bad data; however, not in
the context of the registry or the profile. The registry only cares that the value is within the
scope of that data type.
So, an actual corrupt profile is when the structure of the registry hive no longer conforms to
the expected structure. I’ve seen this two times in 13 years and in both cases it was not
exclusive to the user’s registry. The corruption persisted throughout registry hives and
multiple aspects of the computer did not function correctly. In both these cases, new users
with new profile as well as existing user with existing profiles experienced the problem.
However, it was noticeable that multiple aspects of the computer were behaving poorly.
Ultimately, the problem was diagnosed to a non-windows binary. The binary overwrote
heap memory that the registry used. The binary modified that data before it was committed
to disk. Then, Windows committed modified memory to disk; thereby misaligning the
registry structure—which is a real corrupt user profile.
Conclusion
Be wary when you hear a co-worker reporting a corrupt user profile. Ask them if they saw
during their most recent snark hunting trip or during their last encounter with a ravenous
Bugblatter Beast. More likely—they’ve seen one of the manifestations we’ve described in
this post. It’s a difficult and time consuming problem to troubleshoot and resolve. But some
additional diligence will surface the real problem.
Mike “The Corrupt Profile Gladiator” Stephens
Back to
top
Search this blog Search all blogs

Top Server & Tools Blogs
 ScottGu's Blog
 Brad Anderson’s "In the Cloud" Blog
 Brian Harry's Blog
 Steve "Guggs" Guggenheimer's Blog
Recent Posts
 ESE Deep Dive: Part 1: The Anatomy of an ESE database December 4, 2017
 Introducing Lingering Object Liquidator v2October 9, 2017
 Active Directory Experts: apply within July 26, 2017
 Using Debugging Tools to Find Token and Session Leaks April 5, 2017
Tags
ADFS AD LDS AD Replication auditAuthentication AuthorizationCertificates DFSN DFSR DFSR
Debug Logging DFSR Migration or UpgradeDFSR Performance Disaster
Recovery DNSFRS group policy Group Policy Preferences infrastructure Jonathan
Stephens KB Articles KerberosLDAP Mail Sack Mike StephensNed Pyle network Other
Blogs Passwords PKI PowerShellProfiles Rob Greene Security Silly
Rabbit SYSVOL USMT USMT Behaviors USMT Component Manifest Reference Windows
7 Windows 8Windows Server 2008 Windows Server 2008 R2 windows server 2012Windows
Vista Windows XP
Archives
December 2017 (1)
October 2017 (1)
All of 2017 (4)
All of 2016 (9)
All of 2015 (10)
All of 2014 (9)
All of 2013 (18)
All of 2012 (62)
All of 2011 (132)
All of 2010 (150)
All of 2009 (215)
All of 2008 (122)
All of 2007 (19)
Tags
 Mike Stephens
 Profiles
1. 7 years ago
sgrinker
Mike
Very nice post. Although would it be possible for you to further elaborate on the few cases
you have run accross? Mostly from a curiousity standpoint, but I would be interested to see
more details on what the real "corruption" looked like, how it manifested, and how it was
ultimately found.
Thanks!
2. 7 years ago
AshleyKnowles
Hi Mike,
Great post!
I'd like to get your opinion on an issue which I don't think you have quite put your finger on
with this post. I suspect it may be on the borderline of being a real corruption (albeit, caused
by something else?).
As a desktop tech a year or two ago (*shudder*, glad to be back in the systems engineering
arena), I had a number of clients who would regularly have the exact same issue as below,
primarily on Windows Vista, but occasionally on XP and 7.
The issue, is two fold (forgive me for not having any event logs etc for further perusal, it was
a while ago). Firstly, it is reported in the event log that the users "CLASSES" registry hive
could not be loaded. Secondly, the registry key
"HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders" was actually
"corrupted" – which I suspect has some relation to the first part of the issue. You could not
even open this key and see the actual registry entries (it wasn't permissions related, either)
Fixing the issue was simple, delete the "Shell Folders" key, and recreate all of it's registry
entries. Everything would then come back fine…
Corruption? Or bad data? That's the question.
Cheers
Ashley
3. 7 years ago
HelgeKlein
As the architect for what is now Citrix's Profile Management product I have been working
with and writing about user profiles a lot. Regarding the common misconception of corrupt
profiles I came to roughly the same conclusion as you, albeit 2.5 years ago. Here is my take
on the subject:
http://www.sepago.de/…/corrupt-user-profiles-do-they-even-exist
4. 7 years ago
MikeStephensMSFT
Sgrinker
I’ve received several requests to elaborate on the scenarios in the article. The plan is to
create additional blog posts with each post providing more depth about the scenarios; and
hopefully a way to allow our readers walk through the scenarios themselves. My hope is to
outline the scenario; provide some background; break it; and then show how we here in
support identify it—that’s the plan at least. I have everything done … in my mind—now I
just need to write it 
I’ll try to dedicate a blog that highlights actual registry corruption (the structure itself);
however, that’s actually more difficult to do while making it look like an accident. But, it
would be a good post if I can swing the details and implementation.
Mike
5. 7 years ago
sgrinker
@Mike
Sounds good, and thanks for the follow-up! Looking forward to the future posts…
6. 7 years ago
Mike Kline
Outstanding post Mike! (and nice Eminem reference) I think as long as there are users and
help desk techs this myth will continue.
I have to admit years ago when I did frontline helpdesk support it was an easy thing to say
to a VIP user. "Your profile is corrupt". You recreate it and have a script to copy from the
old to the new and they are back up and running and you get out of their office as fast as
possible.
I like the virtual machine idea; that was not around when I was help desk…would have been
nice.
Thanks
Mike
7. 7 years ago
MikeStephensMSFT
Ashley,
Thanks for the comments. The first issue you mentioned is Windows’ inability to load the
user’s CLASSES registry hive. This registry key is backed by the file usrclass.dat. It’s just
registry data. The key is HKEY_CURRENT_USERSoftwareClasses. The idea behind this is to
allow per-user COM registration. For XP and 2003, you can enable USERENV logging to track
down while Winlogon is having a problem loading the file – there should be an error
message and usually and result code. Other ways to track this down is to use Process
Monitor and log the profile load. Filter File and registry events that involve the filename or
registry location, respectively. Most of the time that Windows fails to load something is
because something else has opened an exclusive handle to the file or registry (95 percent of
the time is a file handle). I typically use Process Explorer and search for the process that has
a handle to the file (sounds like another blog post). If you’re lucky, the process will be
intuitively named to where you can identify the “dood” that isn’t playing nice in the
sandbox. Sometimes, the process will be SVCHOST, which now you need to further
investigate all the services living in that SVCHOST process. The worst scenario is when the
process comes under SYSTEM. The likely of culprits in this scenario is a kernel mode driver
that has a handle to the file. Unfortunately, this requires a debugger and copious amounts
of free time. However, you could ask the question “What uses a filter driver and constantly
looks at files on the operating system?” Antivirus and intrusion protection software are two
big ones that come to mind. Uninstall these (disabling does not remove the kernel driver—
that why we uninstall) and reproduce the problem. The bad thing with that is the reboot
kills your repro.
Second issue – you claim the shell folders keys were corrupt—define corrupt? Shell folder
keys are stored in ntuser.dat, not usrclass.dat so, I’m disinclined to believe the two events
are related—especially when I’d guess the first problem is a handle problem and not an
actual problem with the registry key. Also, I’m a bit confused that the key was impossible to
read; however, some way it could be deleted. Typically, you need to be able to read
something to delete it. Without data, I’d lean toward something wrote “bad” data to these
keys, or they were empty. I’ve seen this before. Again, I turn to trusty Process Monitor to
identify the process “that massages” those keys into porridge; and go from there
8. 3 years ago
anonymouscommenter
,Belstaff Maple jacket brownhttp://w Belstaff Maple jacket brown
ww.belstaffsonline.com/Belstaff-Men-Maple-jacket-brown-acid Belstaff New Panther jacket
black
Want to know more about this week’s guest and topics?

Try clicking on some of these
9. 3 years ago
anonymouscommenter
Republican Sen. John McCain sa mens belstaff brad leather jacket ys the fate of Ar Belstaff
Wallingford jacket izona’s controversial SB 1062 measure is in Gov,mens belstaff brad
leather jackethttp://www.belstaffsonline.com/belstaff-men-jacket-button-brad
10. 3 years ago
anonymouscommenter
Freeeeeeee customized wristbands cheap eee wristbands he
http://www.silicon-wristband.com re!we supply 100 free wristbands everyday,contact us
and get it.we also supply cheap silicone wristabands no minimum,if you need customized
wristbands cheap,pls
11. 3 years ago
anonymouscommenter
Custom Silicone Custom Silicone Wristbands Wrist make your own wristband bands for
PromotionIt’s often that a person or group of people want to get the word out about
something at an event. The thing i silicone rubber wristbands s, people don’t want to
12. 3 years ago
anonymouscommenter
Embossed, Prin silicone rubber bracelets ted, Debossed and More!
There is often a lot of confusion regarding the vari Silicone Rubber Wristband ous styles of
custom made silicone rubber bracelets. Heck, even silicone wrist band vendors mix-up
debossed

Windows Perfomance Troubleshooting

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Windows Perfomance Troubleshooting

Transféré par

Droits d'auteur :

Formats disponibles

http://labmice.techtarget.com/troubleshooting/PerfMon.

Lesson 3: Using Process Explorer to Troubleshoot and Diagnose

Somebody should be in jail, but they are probably on a yacht.

Lesson 4: Understanding Process Monitor

Analyze an Offline System (As in Hooking Up a Hard Drive to Another PC)

Use BGInfo to Build a Database of System Information of Your Network Computers

When the Utilities Won’t Connect Because of Remote Registry

How to Hide Data in a Secret Text File Compartment

SDelete Securely Deletes Files

Contig Defragments One or Many Individual Files

MoveFiles Moves System Files when You Reboot

Junction Creates Symbolic Links

Disk Monitor Shows You Real-Time Hard Drive Activity

If only the icon matched Windows 8 a little better.

4. Extract the archive to the folder C:\monitor created in step 2.

5. Double Click on the file “Procmon.exe”

6. Click on the “Capture” icon to stop the capture process.

25. Select the “Cancel” button to close the window.

Use “Process Monitor” for “Boot Logging”

3. Double Click on the file “Procmon.exe”

6. Now go in to the “Options” menu and select “Enable Boot Logging”

7. The following dialog box will open.

9. Reboot the system

15. Click “Yes” to save the collected data.

16. This will open the Save As dialog box.

The Case of the Veeerrry Slow Logons

Information on troubleshooting using windows sysinternals.

1. Download the WinDBG sdksetup.exe setup file.

Associate .dmp files with WinDBG

cd\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

This is how it looks when executed in the cmd window.

Configuring the WinDBG Symbol Path

To create and set a symbol path, do the following.

1. Start a blank instance of WinDBG by going to:

2. In the WinDBG panel, go to:

File > Symbol File Path

What that line means is :

 Create a folder called C:\SymCache

4. Save the symbol path by going to:

File > Save WorkSpace

Testing the WinDBG Installation

1. Download this small zip file.

2. Open it, and double click the .dmp file.

 A folder called Symcache is being created on C:

 Symbols are being downloaded and saved to C:\Symcache

Use !analyze -v to get detailed debugging information.

BugCheck 24, {1904fb, fffff88008f94c48, fffff88008f944a0, fffff80002ddde2e}

Probably caused by : ntkrnlmp.exe ( nt!FsRtlNotifyFilterReportChange+122 )

To close WinDBG go to File > Exit

The Windows 7 Boot Process (sbsl)

Written by Claus Witjes and Arne Stremlau

Boot Process Overview

Whitepaper . Common performance vulnerabilities are described in the whitepaper as

The PostBoot phase

Troubleshooting Windows Startup Problems

ping -t raymond.cc|cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" &&

WinDBG - The Basics for Debugging Crash Dumps in Windows 10

WinDBG - The Basics for Debugging Crash Dumps in Windows 10

Part One: WinDBG Installation and Configuration

To install and configure WinDBG follow WinDBG - Install Configure - Windows 10

Step One: 7Zip and Opening Dump Files

EXAMPLE: Dump window manually resized for larger viewing area:

Step One: Bugchecks At a Glance