A script that doesn’t throw an error but doesn’t do what you want it to do is encountering an error. Perhaps this is a moot point but I thought it was comical because one of my co-workers couldn’t figure out why his script wasn’t working and not “erroring” until he mentioned a few minutes later that he included On Error Resume Next in the script. The lesson learned is that you should comment-out this line out until you have a fully functioning script. Afterwards, this little lesson then reminded me that at some point awhile back I meant to write a blog about commenting out On Error Resume Next until you have a full functioning script but really didn’t think I had enough to warrant a blog. Well, with this little incident, now I have a decent paragraph to put into a blog post.
Archive for May, 2012
On Error Resume Next
Posted by William Diaz on May 18, 2012
Posted in Uncategorized | Leave a Comment »
Wife.exe Crash Troubleshooting
Posted by William Diaz on May 18, 2012
Not all issues I troubleshoot are at work. Sometimes I might be sitting at home and then this somewhat buggy application starts up. It’s a random occurrence and trying to resolve its problems can be very taxing. The main reason for this is I don’t have the source code and trying to reverse-engineer it is nearly impossible because it’s data structures are not logical. But maybe we can look at its crash dump and find out what’s happening.
Looking at the dump:
Posted in Troubleshooting | Tagged: Crash, Dump, WinDbg | 2 Comments »
Troubleshooting Excessive Interrupts & DPCs
Posted by William Diaz on May 14, 2012
After logging onto my main home PC and opening IE, I noticed lag while repositioning the window around the screen. I opened the Task Manager, sorted by the CPU column and saw no single process reporting excessive usage: 
Nor was the hard disk light blinking or solid. However, looking at the Performance tab revealed two of the CPU cores hovering around 100%:
Posted in Troubleshooting, Troubleshooting Tools | Tagged: Performance | Leave a Comment »
You Might Have Resolved that Networking Issue Because You Unknowingly Broke Your Firewall (but also isolated the cause)
Posted by William Diaz on May 10, 2012
A lot of vague networking issues on user workstations are sometimes troubleshot by running the netsh winsock reset catalog command, often without knowing what it does. When you run this command, you are resetting the layered service providers that come with Windows and removing all others that did not come with Windows. These “others” might be MS firewall clients, security proxies or 3rd party wireless communication apps that come with “Air Cards” used by mobile users.
In the environment that I work in, our workstations have the Microsoft Firewall Client or TMG client installed. You can directly see this as a layered service provider by opening msinfo32 and going to Components > Network > Protocol: 
If you run netsh winsock reset you end up removing any LSPs that are not part of the Windows-Out-Of-The-Box installation. If your LSP application is self-aware, like in the case of the MS FWC or TMG client, you might notice a warning of some type: 
This is a sign you need to run a repair or reinstall your LSP application (in this case, a repair of the FWC\TMG client is enough to fix and put the LSPs back in place).
The irony is that, if running netsh winsock reset resolved whatever mysterious networking issue you encountered, then you might have isolated the cause of the issue to a problem with the LSP application. I encountered this myself way back in my first blog post of the The Case of the Random Internet Explorer Crashes.
Posted in Troubleshooting | Tagged: Networking | 2 Comments »
(Stupid)UserException
Posted by William Diaz on May 8, 2012
Sometimes the user is just wrong and you can’t give them any other choice but to admit it.
Posted in Uncategorized | Leave a Comment »
The Case of the Runtime Error (or Check Your Time Zones & DST Settings)
Posted by William Diaz on May 7, 2012
One of our helpdesk technician’s in a remote office reached out to me recently and asked me to assist with an application that suddenly started crashing on him with the following error: “Microsoft Visual C++ Runtime Library. Runtime Error! This application has requested the Runtime to terminate it in an unusual way…” 
Posted in Troubleshooting, Troubleshooting Tools | Tagged: Crash, Dump, Process Monitor, WinDbg | 1 Comment »
Troubleshooting a “Hard Hang”
Posted by William Diaz on May 7, 2012
I recently put together a quad core system from parts my brother was retiring from his home system. Soon after getting everything up and running, the new system would sometimes hard hang while working via VPN. A hard hang is when the OS becomes completely unresponsive but is still running. I had earlier prepared myself for the next instance of this encounter by enabling CrashOnCtrlScroll in the Windows registry so that the next time it happened I could manually crash the system from the keyboard and examine the memory dump with WinDbg for signs of the responsible culprit. You can read about how to enable this option in this earlier blog Forcing a System Crash on an Unresponsive PC.
Upon opening a kernel dump, the analyze –v command is a clickable hyperlink1.
Posted in Troubleshooting | Tagged: Crash, Dump, Hang, WinDbg | 1 Comment »
Recovering Text From A Unresponsive Application
Posted by William Diaz on May 2, 2012
A couple weeks ago a co-worker asked me if it was possible to recover text from a hung application. The user had spent a good amount of time typing into text field and upon trying to submit the information, IE became hung and would not recover. The user didn’t want to have to retype everything from scratch again. The short answer to this is yes. The long answer is “Yes, if you can be patient.” I have never actually needed to perform this myself because it’s not always that practical and, to be honest, the task can be somewhat tedious. But if you really need to recover text and Word didn’t auto-recover or Outlook lost the draft after you clicked send, or IE is in the process of a “GUI crash”, then turn to the power of the dump.
The idea here is if the application is still running but stalled, it still resides in memory, along with anything you typed into it. When you dump the process, you are dumping its presence in memory to a file that you can pick apart. Dumping a hung process is simple enough. On an XP system, open Process Explorer, right-click the process, and choose Create Dump. In Vista & Windows 7, this option is now built into the Task Manager. You can then copy the dump to a system where WinDbg is installed to open it.
Posted in Troubleshooting Tools | Tagged: Dump, Hang, WinDbg | Leave a Comment »
Quickly Configure Symbol Information for Process Monitor & Process Explorer
Posted by William Diaz on May 1, 2012
I often find myself running Process Monitor and Process Explorer on user workstations. But to get the most of either of these tools, you really need to configure symbols so you can accurately read thread and stack information when doing a deeper analysis of a process. This can often be a nuisance because I am a cut and paste type of guy and even after doing it numerous times, I still have trouble recalling the Microsoft symbol path. On top of that, many times I run these tools with the user connected so speed is a necessity. To work around that, I decided to write a small script that I can run from a file server that will do it for me. Run the script before your start either tool.
There is one prerequisite, however: you need the full dbghelp.dll from the Windows Debugging Tools as the debug help DLL in system32 is not sufficient. If you are running on both 32 and 64 bit systems, you will need to get both the 64 bit and 32 bit versions. Store them away on network share and modify the script below to look to that share. In my case, we are still a mixed environment so I renamed the 32 bit dbghelp to dbghelp32.dll while the 64 bit version remains unchanged and created two different scripts. The respective DLL will copied into a folder C:\DbgHelp on the local system .
I also added a 5 second duration for new open and close processes and threads.
|
const HKEY_CURRENT_USER = &H80000001 strValueName = "DbgHelpPath" strValueName = "SymbolPath" strValueName = "HighlightDuration" ‘Process Monitor 64 strKeyPath = "Software\Sysinternals\Process Monitor" strValueName = "DbgHelpPath" strValueName = "SymbolPath" ‘Copy full dbghelp.dll 64 bit to folder DbgHelp. Set oFSO = CreateObject("Scripting.FileSystemObject") Set FSO = CreateObject("Scripting.FileSystemObject") |
Posted in Troubleshooting Tools | Tagged: Process Explorer, Process Monitor | Leave a Comment »
Investigating & Resolving Message Delays in Outlook with WinDbg
Posted by William Diaz on May 1, 2012
The problem starts after the user has had their Windows profile recreated but continues to experience some Outlook performance issues. Each time she clicks the New button in Outlook to create a new message, there is a 5 to 10 second delay before the blank message opens. There is also a 10+ second delay after she clicks send and Outlook becomes unresponsive for that time. I connect to her and quickly look at the Office Outlook registry for any unapproved 3rd party add-ins and see nothing out of the ordinary. I decide to dump the Outlook process when the hang is encounter and turn to Process Explorer. This is a simple matter of right-clicking the process and choosing Create Dump when it is in an unresponsive state. Actually, I collect two dumps, the other with Procdump in hang mode. I do this to ensure that the dumps are consistent; if the dumps are not similar then I may need to collect more until a pattern emerges.
I copied the dumps to my workstation and opened them with WinDbg and run the !analyze –v –hang command. The stack for both dumps are similar. With the exception of the NRTExchn component (our DMS add-in for Outlook), these are all MS modules. Normally, this wouldn’t excite me but something stands out like a sore thumb as I move up the stack, the presence of msi.dll in the stack of the current examine thread.
Posted in Office, Troubleshooting, Troubleshooting Tools | Tagged: Hang, Outlook, Process Explorer, Process Monitor, WinDbg | Leave a Comment »
Windows Explored 