Windows System Crash Analysis (BSOD)

You are all probably aware of the MEMORY.DMP files in the windows directory. You may also be aware of the Windows\MiniDump directory. These files are created when there is a critical system error usually resulting in an automated reboot or BSOD.

The Memory.DMP file contains debugging information plus the contents of your system’s RAM. This file is overwritten each time a crash occurs. The MiniDump directory contains the same debugging information as MEMORY.DMP but does not include the RAM contents. The MiniDumps are not overwritten so they can be used as a historical reference for identifying crash events.

So the question is how do you use these file???? There is a tool from Microsoft designed to do just that! It is called WinDbg and is part of the Debugging Tools for Windows. (

Download and install this tool. There is an x86 and an x64 version. Once the program is installed open it and choose the file menu then Symbol File Path.

Enter the following:

This will download the necessary symbols as needed. Symbols are a link between the binary application code and programming language which generated the code.

Once this is done you can choose File – Open Crash Dump. This will open both Memory.DMP and MiniDumps. Once opened the program will begin some analysis.

Click on the !analyze –v link to do a verbose analysis. This may give more information as to the reason for the crash. The faulting application code is listed in the default analysis.


PCI-DSS Compliance for RDP Connections

This is a common problem that you’ll see from PCI-DSS compliance audits for customers which process credit cards on their PC network. In many cases simply disabling external RDP access is the answer, but when external RDP access is required, here is the proper way to address the following two errors:

  • Microsoft Windows Remote Desktop Protocol Server Man in the Middle Weakness (CVE-2005-1795)
  • Terminal Server Encryption Level is not FIPS-140 compliant

What I have seen other companies do is simply restrict RDP to a specifc set of WAN IP’s, which will appear solve the problem from the PCI audit report because they cannot access the RDP port open due to the firewall rules, however this is still a violation of PCI because the vulnerabilities still exist. The protocol needs to be properly secured, and the process is relatively simple.

1)      Create a self-signed SSL certificate (if one doesn’t already exist; of course a publicly signed SSL is better, but not needed for PCI compliance)

2)      Open Terminal Services Configuration

3)      Edit the properties of the RDP-Tcp  Connection

4)      Start from the bottom and work up

  1. Click Edit and add the self-signed SSL certificate
  2. Set the encryption level to FIPS compliant
  3. Click APPLY
  4. Set the Security layer to SSL (you will not see this as an option if the SSL cert is not configured and you haven’t applied the changes)
  5. Click APPLY again then OK

5)      Close all windows and all active RDP sessions

Simply have the PCI Compliance company run a new audit and you should be all set.

Reviewing Server Uptime/Downtime

Whenever troubleshooting server uptime/downtime, I typically start by installing a simple Microsoft tool, uptime.exe which will basically parse the event log for shutdown related events and provide a simple table of the system uptime, along with reasons. You can perform a historical seach, such as the last 60 or 365 days, or whatever number you’d like; you just need to have the event logs to support that query. It will let you know if you don’t have enough event logs, and will show you whatever it can.

It typically do this when troubleshooting a server which appears to be restarting without reason. It permits you to easily see each time the system restarted, which can sometime reveal a pattern. When I see reboots at 3am, I think Windows Update (for example) or a reoccuring on the weekends. Sometimes it makes it easy to figure out like a scheduled task or other such event. Othertimes, it appear totally random.

You can find it at:

Shared Fax Server on Windows Server 2003

3d human try to turn the pageEver since I began using Microsoft Small Business Server 2000, I was thrilled with all of the features included which were not found anywhere else by Microsoft. Many of the useful features required third-party add on tools. One such tool was the shared fax server.

Beginning with Microsoft Windows Server 2003, a shared fax server became a built in feature. However documentation on how to implement this new feature is sparse at best. This documentation is based on a Windows 2003 Server (all editions except Web), and Windows XP for your client. Continue reading “Shared Fax Server on Windows Server 2003”

Dell Broadcom Drivers

usb cableWe experienced a strange problem lately with a client where we enabled the second Broadcom integrated NIC on a Windows 2003 Enterprise Server. What we discovered was that when we set the static IP address on the server’s second network adapter, the first network adapter dropped into this semi-DHCP state. When we corrected the first adapter, the second one would go into the semi-DHCP state. I say semi because it actually showed the adapter in DHCP mode, but unable to find a DHCP server so it used the automatic IP address – which is typically 169.x.x.x, but instead of that, it actually retained the static IP address. But when the server rebooted, it would loose the static IP address (since it was set to DHCP mode) and would pickup a new, dynamic IP address.’

So I performed the normal troubleshooting steps from uninstalling the network drivers, reinstalling the existing driver, and then finally installing the latest drivers – which would always fail. So after a bit of messing around I called Dell Enterprise Support and to my surprise the provided a shocking list of prerequisites before we could upgrade the drivers…

Continue reading “Dell Broadcom Drivers”

Powered by

Up ↑