Posted by William Diaz on November 28, 2011
i.e., it crashes.
When processes exit, they should exit with a status code that indicates whether or not it exited gracefully or abnormally. This comes in helpful when you need to examine large Process Monitor logs and want to isolate the time of the crash. Simply filter for Process Exit:
Read the rest of this entry »
Posted in Inside Windows | Tagged: Crash, Process Monitor | 1 Comment »
Posted by William Diaz on November 7, 2011
Sometimes, the obvious is over looked because error messages often do not allude to the actual problem being encountered. For example, the online document management service eRoom presenting the following error when trying to open a file: “Unfortunately, eRoom was unable to open this file, because the directory could not be found.”
At first glance, this doesn’t means anything. But examining the settings of the application provides a clue:
Read the rest of this entry »
Posted in Inside Windows, Troubleshooting | Leave a Comment »
Posted by William Diaz on November 2, 2011
Often times when sorting through Process Monitor logs, you find yourself having to employ some intuition to zero-in on what is an otherwise vague result: NAME NOT FOUND. Its normal to see these results en masse, and most of these are perfectly legit. But knowing how to apply a few filters and some basic understanding of what you are looking for is sometimes enough to narrow down why your application is failing. In a previous post, I demonstrated this approach. Here is another example.
In this case, the user was not able to open PDFs from within our Outlook-integrated document management system. The error reported was rather generic as you can see below: Read the rest of this entry »
Posted in Troubleshooting Tools | Tagged: Outlook, PDF, Process Monitor | 1 Comment »
Posted by William Diaz on November 1, 2011
Account locks normally are not a big deal to troubleshoot. Often times it is a user typing in an incorrect password to the account they are trying to logon to too many times. Other times, it is being caused by expired or incorrect cached credentials being used to authenticate to some network resource. In the latter case, this is a simple matter of going onto the workstation that has been identified as one locking the account and removing the cached credentials.
In Windows XP, this can be done by going to Start > Settings > Control Panel > User Accounts > Advanced (or Manage Passwords for non-admins) > Advanced > Manage Passwords. Alternatively, you can just use the control userpasswords2 command.
Read the rest of this entry »
Posted in Troubleshooting | Tagged: Networking, Printing, TCPView | Leave a Comment »
Windows Explored 