There’s no question that the Windows Debugger (windbg.exe) is a nonpareil tool when it comes to troubleshooting source code or digging into Vista crashdumps. But with the program’s requirement for current debug symbols, complex syntax (the downside of amazing functionality is detailed and demanding syntax), and vast power comes a certain amount of effort required to get things set up and working properly. If all you want is a quick peek at certain key fields in a full-blown crash dump (C:\Windows\Memory.dmp by default) or a minidump file (C:\Windows\Minidump\Minimmddyy-0x, where mmddyy maps into 120808 for December 8, 2008, and the x represents which minidump acquired that day you’re after, so that my December 8, 2008 mindump file is named Mini120808-01.dmp) the lightweight dumpchk.exe utility may be more to your liking.
Given the following filename example, here’s a pared-down snapshot of the command line input for dumpchk and its response:
c:\Temp>dumpchk c:\Windows\Minidump\Mini120808-01.dmp -e Loading dump file c:\Windows\Minidump\Mini120808-01.dmp ----- 32 bit Kernel Mini Dump Analysis DUMP_HEADER32: MajorVersion 0000000f MinorVersion 00001771 KdSecondaryVersion 00000000 DirectoryTableBase dc05e3e0 PfnDataBase 8236b850 PsLoadedModuleList 8234bc70 PsActiveProcessHead 82341990 MachineImageType 0000014c NumberProcessors 00000004 BugCheckCode 00000101 BugCheckParameter1 00000031 BugCheckParameter2 00000000 BugCheckParameter3 803d1120 BugCheckParameter4 00000001
The key information appears in the BugCheckCode entry (this maps to the Windows Stop error code that shows up on a bluescreen), and the four parameters that follow. A quick Google search on the Stop Error code presented as a Hexadecimal number of the form 0×00000101 is usually all it takes to find guidance on causes and potential fixes for such errors. In this case, I had to accept a light slap on the wrist for excessive over-clocking on my QX9650 processor and turn the clock rate back down in my PC’s BIOS (a reduction from 3.5 to 3.2 GHz did the trick nicely).
Sure Windbg.exe will do the same tricks, and a whole lot more, but why not use the quick’n’dirty dumpchk.exe if it will do the trick. If you download the Windows XP SP 2 Support Tools (Windows validation is required) you can grab and use dumpchk.exe on Windows Vista without difficulty.
Sometimes, the information I come across on Vista internals is just too good not to pass along. And when it comes to Vista internals nobody knows (or does) them better than Mark Russinovich, formerly a principal at SysInternals, now a Microsoft Fellow. In discussing paging file sizes in the context of Vista, Mark makes the following wonderful observation which accords entirely with my own experience:
There’s no end of ridiculous advice out on the web and in the newsstand magazines that cover Windows, and even Microsoft has published misleading recommendations. Almost all the suggestions are based on multiplying RAM size by some factor, with common values being 1.2, 1.5 and 2.
This comes from his November 17, 2008 blog entitled “Pushing the Limits of Windows: Virtual Memory,” wherein he also digs into process address spaces, explains how virtual memory gets mapped in the 32- and 64-bit worlds, and talks about committed memory that processes essentially get to own as they’re executing and the commit limit that sets the ceiling on such allocations. Along the way, he also uses his snazzy Testlimit (and Testlimit64) tool to demonstrate these principles in action.
All this detailed and exquisite discussion leads back to what’s really involved in sizing a paging file. It is best to understand that the commit limit imposes a ceiling on how much private (process-based) and pagefile (system-based) virtual memory can be allocated at any given moment by actively running processes. Thus the key comes from knowing the total sum of commit charges for all programs you’d like to have running concurrently. The commit limit must exceed that sum, or trouble will ensue.
His sizing approach is pretty simple: fire off all the applications you’d like to use together, then use SysInternals Process Explorer to measure the Peak Commit Charge. In fact, Russinovich recommends examining this value after running your target collection for a while to make sure you reach maximum load. After that, the formula is:
Size of Paging File = Peak Commit Charge – Amount of Physical RAM in system
If that number is negative, that doesn’t mean you want no paging file. It should be set to no smaller than whatever kind of memory dump you’ve got configured for crash reporting (default value is around 135 KB or miniscule, but a complete memory dump has to match the amount of accessible memory–same value that shows up as Total under Physical Memory in Task manager–for that memory dump to occur). By default Vista sizes the paging file to equal total memory plus 300 MB or 1 GB, whichever is larger. On my Vista machine my maximum commit limit runs at around 2.5 GB, but I’ve left the paging file alone at 3881 MB (equal to usable memory of 3,581 MB plus the aforementioned 300 MB) so I can generate a memory dump if and when I must.
On notebook and desktop PCs not quite so lavishly endowed with RAM, you can probably get by with cutting the paging file somewhat by following Mark’s formula. If you need to capture a memory dump at some point, you can always increase the paging file to accommodate that need for so long as you must capture memory dumps, then revert to earlier values after that exercise concludes.
The second Tuesday in each month is when Microsoft schedules its patches, fixes, and security updates. Recently, Microsoft has begun to offer Advance Notification for its Security Bulletins, which makes it a lot easier to tell what’s coming down the pike. For December, 8 updates have been pushed to the Windows Update servers
Of the 8 items for Vista that appeared on December 9, 6 are rated Critical and 2 Important. Here’s a brief summary of what you’ll find:
MS08-71: Vulnerabilities in GDI Could Allow Remote Code Execution
Permits a specially crafted WMF image file to inject remote code execution at the system level.
MS08-75: Vulnerabilities in Windows Search Could allow Remote Code Execution
Blocks vulnerabilities that could occur if a user opens and saves a specially-crafted save-search file in IE or clicks a similar search URL.
MS08-073: Cumulative Security Update for IE
Resolves 4 privately reported vulnerabilities including remote code execution.
MS08-070: Vulnerabilities in Visual Basic 6 Runtime Extended Files (ActiveX Controls) could allow remote code execution
Resolves 5 private and 1 public vulnerability in ActiveX controls for VB 6.0 Runtime Extended files.
MS08-072: Vulnerabilities in Microsoft Office Word Could Allow Remote Code Execution
Resolves 8 privately reported MS Office and Outlook vulnerabilities related to Word or RTF file contents that devlier access at the system level.
MS08-074: Vulnerabilities in Microsoft Office Excel Could Allow Remote Code Execution
Resolves 3 privately reported vulnerabilities possible from specially-crafted Excel files that provide system-level access.
MS08-077: Vulnerability in Microsoft Office SharePoint Server Could Cause Elevation of Privilege
Resolves a privately reported item that allows elevation ofprivilege when authentication is bypassed by browsing to an admin URL on a SharePoint site (might result in DoS or unauthorized access).
MS08-076: Vulnerabilities in Windows Media Components Could Allow Remote Code Execution
Resolves 2 privately reported vulnerabilities in Windows Media Player, Windows Media Format Runtime, and Windows Media Services that could allow remote code execution at system level privilege.
The first six are rated Critical, the last two Important. Vista admins will probably want to start working with all of these that apply to their environments (including SharePoint and Windows Media, where applicable) because all come with potentially dire consequences if they remain unpatched. Hopefully, none of them will cause too many compatibility problems. Nonetheless I advise you to get testing underway ASAP.
I just saw an interesting story from Ryan Naraine on ZDNet that puts these Vista Updates into a different context. He calls this patch Tuesday a “whopper” because it mentions that 28 vulnerabilities in Windows, IE, and Office are addressed, of which 23 are rated “Critical.” He counts each of the reported items addressed in the preceding list of security bulletins to come up with these numbers, which certainly adds to the drama. I guess it’s all in how you play out and drum up those numbers! He also mentions that other security experts from Shavlik agree that it’s wise to start planning a roll-out of these patches ASAP because of the vulnerabilities they expose.
In the process of compiling data for a review on notebook PC coolers recently, I had my face slapped by some dramatically different data from the selfsame notebook PCs as I sought to document the influence of an added external cooler when it came to running a notebook. This phenomenon might be expressed as “saving electricity saves on heat output too.” Of course the physics of solid state and electrical devices are such that the more electricity they use, the more waste heat they produce as a matter of course–this is by no means rocket science, to be sure–but what is striking is the sheer magnitude of the changes involved.
A short table of values (see below) tells the story in a pretty interesting fashion. I let three different Vista notebooks run at idle and then put them to work defragmenting their system drives (using the excellent Raxco PerfectDisk 10 beta product, which I’m also currently working with right now) using all three of their predefined power regimes (called power schemes prior to Vista’s introduction, called power plans inside Vista today; see this MS Help FAQ on Power Plans for more info):
- Power Saver:
Saves power by reducing system performance, to help notebook PC users maximize battery life (also results in cooler operating temperatures).
Saves some power by reducing system performance while systems are idle, but also boosts capability (and power consumption plus heat output) during peak demand periods.
- High Performance:
Maximizes system performance and responsiveness, resulting in shortened battery life and higher operating temperatures.
Notebook-Idle PS Bal HiP Dell D620 25-27 25-41 25-53 Acer 8920G 32-36 35-38 36-40 HP HDX 18 35-37 35-38 36-47 Notebook-Defrag PS Bal HiP Dell D620 25-46 27-57 27-65 Acer 8920G 32-40 35-45 36-46 HP HDX 18 35-41 35-43 36-47 Note: PS = Power Saver, Bal = Balanced, HiP = High Performance, all temperatures are in degrees Centigrade (° C).
What’s interesting about the data in this table is that the temperatures run more or less the same for these power plans whether or not they’re plugged into a wall socket or running off battery. What this tells me is that enterprises can save money on hardware by extending its life with cooler-running power plans, to a much greater degree than might immediately seem possible. Though results do vary as the Table data shows, it’s also the case that using the Power Saver on the road/untethered, and the Balanced plan in the office/plugged-in, and High Performance never will save wear and tear on notebook PCs and let companies use them for a while longer than they may have expected them to last. Sure, they’ll also save a little on power as well, but I’d expect to see the savings on equipment overshadow those numbers significantly. The question then becomes: Will the users go along with this approach? I didn’t notice much performance difference between Balanced and High Performance, but the step down to Power Saver caused the GUI to run noticeably (though not painfully) slower.
Last week I blogged about Danish information security firm Secunia’s outstanding Network Software Inspector. In that capsule summary I neglected to mention that Secunia sends out e-mail updates to all registered users any time the rules base gets updated.
This turns out to have significant value, of course, because some updates are more important than others–Microsoft Security Updates are probably the best example, especially those pushed to Windows Update outside the usual Patch Tuesday cycle. In this case, my reminder came in the form of an observation that Sun had released a new set of Java and Java Runtime Executable (JRE) updates, which addressed some reasonably serious (Category 4) vulnerabilities from the previously-current version.
This was all the information I need to go out and grab the updates for the various Vista and XP machines that I work on every day. In an enterprise setting, the same email can trigger the download-test-push cycle that’s more typical for updates in such environments. Either way, timely access to this kind of information is absolutely invaluable, and lets us all respond more quickly as and when known vulnerabilities are patched or fixed.
The Secunia vulnerability scanning toolset is a good one, and this real-time e-mail update service only makes it better. I hope you’ll check it out, and try it out, in your own environments.
I guess those guys at TechARP really must have some good sources: less than one week after they shared leaked information about release dates and content for Windows Vista SP2, Microsoft has announced its Customer Preview Program (CPP) for a single SP2 that will cover both Windows Vista and Windows Server 2008. This leads me to several interesting observations:
- There must be much more to the common code base that purportedly exists between Vista and Server 2008 than many had previously thought–including me–because a single set of executables (32-bit and 64-bit binaries, in the usual variations) will address both OSes.
- The Notable Changes document mentions a change to the Windows Update Agent/Windows Update Service stack as a pre-req to installing this service pack.
- The Windows Update versions will be between 302 and 390 MB in size for standalone packages, and from 41 to 47 MB for Windows Update downloads (32-bit packages). For x64 64-bit packages, these numbers vary between 508 and 622 MB for standalone, and 60 and 90 MB for Windows Update versions.
- The new features list matches what I reported from TechARP exactly, except for the omission of updates to the RSS feeds sidebar gadget to improve performance and responsiveness.
- Numerous enterprise (full addition of Hyper-V into 2008, improved power management policies, and improved backward compatibility for Terminal Server license keys) and setup and deployment (single installer for both Vista and 2008, driver incompatibility checks during install, better error handling and reporting, improved installation logging and security, and another clean-up tool to rid the drive of files that SP2 will supersede) features will debut in this service pack.
- There’s also mention of running the clean-up tool offline while creating slipstream install images to reduce overall image size. I’m curious to see how this will play out in day-to-day use.
As I write this blog, the SP2 download is available only to TechNet and MSDN subscribers (drat! I gave up my TechNet subscription as of 1/1/2008, and this is the first time I’ve missed it since then). On Thursday, 12/4/08, it became available on its own Beta CPP page [added 12/5/08].
Of course this information begs a very important question for enterprise Vista admins to ponder: why would they care about this beta? Instead of thinking of it as another distraction from important tasks and activities, think of it as an early opportunity to look for potential install, deployment, and compatibility issues. Although the full-blown release won’t go live until April09 at the earliest, it’s never too soon to start weeding out the potential gotchas from the work that a full-blown rollout will inevitably bring. That’s why you’ll probably want to download and work with this beta, albeit in the context of a safe and isolated test lab setup.
Adrian Wong’s TechARP Web site (here ARP stands for “Adrian’s Rojak Pot” not “Address Resolution Protocol” BTW) has been a reliable source of advance information about upcoming Windows Service packs for some time now. Just before Thanksgiving he disclosed some information about the next Vista Service Pack (Vista SP2, that is) which is probably of great interest to IT professionals who feed and care for Vista installed bases of any size. Apparently SP2 for Windows Server 2008 will also ship on this same schedule (but that’s outside my bailiwick so I won’t say more about it here, though you can find details in the pointers at the end of this blog).
Here’s the scoop on projected dates:
- Windows Vista SP2 release candidate should hit some time in February, 2009
- Windows Vista SP2 RTM (release to manufacturing) should follow a couple of months later, in April, 2009
- Dates for release online and through Windows Update have yet to be determined, but will occur in several waves, by language. As with Vista SP1 and XP SP3, English, German, Japanese, French and Spanish will probably come first, followed by Chinese, Korean, and Brazilian Portugese next, with other languages later still. If those recent releases are any indicator, the first wave will follow about three weeks after RTM, and the second six more weeks after that. Thus, we’re looking into May for the first wave and June or July for the second one.
The major updates in SP2 are said to include the following items:
- Windows Search 4.0, to deliver speedier, more accurate searches on the desktop
- Bluetooth 2.1 Feature Pack, to deliver support for the more recent Bluetooth Technology spec, especially beneficial for battery life when wireless human interface devices–namely, mice and keyboards–are in use
- native Vista support for burning to Blu-ray disks
- updates to Windows Connect Now (WCN) to offer improved, simplified Wi-Fi Configuration
- adds UCT timestamp support to exFAT file system used on Flash drives, and permits proper time synchronization across time zones
Of course, there will also be the usual roll-up of patches, fixes, and security updates since SP1 became available on 3/4/2008 (RTM, we actually didn’t see it online until about three weeks later in the month). But it looks like there will actually be some useful functionality upgrades, especially for Blu-ray burners, Bluetooth, Wi-Fi, and Flash drive file systems. Likewise, any slippage that occurs will also be interesting to follow (dates may slip out further and are much less likely to slide in closer).
The original source for this information comes from two TechARP editorials:
1. ED#107: Latest Details on Windows Vista Service Pack 2
2. ED#106: Windows Vista Service Pack 2′s Latest Release Schedule
On 11/25/2008 Microsoft pushed a slew of updates out the door For Windows Vista, as follows:
- KB957321 – An update to add support to the XMP specification for complex data types in the Windows Imaging Component
- KB959108 – An update is available that disables the collection and transfer of Software Quality Metrics data by the Windows Portable Device (WPD) API
- KB959130 – When you run the “Connect to the Internet” Wizard and select the “Browse the Internet now” option, Internet Explorer starts instead of the default Web browser that you set in Windows Vista or in Windows Server 2008
- KB957241 – Updates for Microsoft Office Access 2007 Help (dated 11/12/2008 in the KB article, but didn’t actually get out until 11/25).
- KB949104 – More enhancements/changes to the Windows Update Agent (WUA) that interacts with Windows Update to search for and download updates from a remote server. Permits further auto-updating of WUA itself.
Except for the WUA item (KB949104), which is marked “Important,” the rest of these items are marked “Recommended.” The whole release, with the possible exception of that WUA item, leaves me scratching my head a little, wondering why MS felt compelled to push these updates out of cycle, rather than waiting for next Patch Tuesday (12/9/2008) to come around. In poking around on various Microsoft Vista and Windows Update newsgroups I don’t see much cause for urgency or alarm in any of these updates, though a few MS Office users do report problems with various applications after applying the help updates (including those posted on 11/12/2008 for most other major Office components).
What is interesting in this batch is the version number associated with the WUA update (7.2.6001.788). Unless my eyes deceive me, and my wits have deserted me, this is the first appearance of a Windows 7 component in the public eye, for general consumption. Most Vista SP1 version numbers take the form 6.0.6001.18000 or something similar, where the 6 stands for “Windows 6″ (Vista) and the 6001 indicates the SP1 build number; this version number combines a Windows 7 reference and the 6001 build number in a single item. I can’t help but wonder what it portends.
Those Vista admins whose charges use MS Office will probably want to push the Access Help update out, and their need for WUA updates will depend on how they handle Windows Updates internally within their organizations (I suspect most will not need it, because they use their own tools to push updates to user machines). The items may require some compatibility testing to determine whether or not they should be pushed out. On the face of what they cover, however, I see no compelling reasons not to wait and handle this other stuff when the next Patch Tuesday strikes on 12/9/2008.
I’ve been working in some depth around Windows security topics since 1997, when I began teaching Windows hardening classes at Interop with my colleague and co-author James Michael Stewart. In 2003, I started researching malware topics and tools, a quest that eventually led to my 2005 book “Fighting Spyware, Viruses, and Malware” for PC Magazine Press. Along that path, I became familiar with Swedish infosec firm Secunia, whose many threat and vulnerability warnings, proof of concept exploits, and timely malware information always proved accurate and reliable.
Yesterday, Secunia released a final version (184.108.40.206) of its Personal Security Inspector, a free, single-shot vulnerability scanner that examines Windows PCs running Windows 2000, Windows XP, Windows Server 2003, and Windows Vista to make sure that Windows Updates are current and correct, and that checks installed applications to make sure they are also patched and up-to-date. The tool flags unpatched code, and end-of-life programs that are no longer being updated, to help individuals update or replace potential sources of vulnerability on their desktops.
For enterprise use, Secunia also makes a Network Software Inspector (NSI, currently at version 2.0) available to companies and organizations that want to perform similar scans on the PCs on their networks. At 20 Euros per machine per year (about $25.68 at today’s exchange rates), it’s not too different from what the Microsoft Baseline Security Analyzer (MBSA) can do for Windows and MS apps. But when you add its substantial (over 7,000 programs) database of applications with security status, and its built-in, easy-to-use, and intelligible remediation advice, NSI comes out way ahead at a very reasonable per-user cost (contact Secunia sales for purchases of over 50 seats, where discounts begin to kick in).
If you’re interested in trying out this outstanding tool, you can download a 30-day evaluation copy at no charge. It’s definitely worth digging into further for those companies or organizations seeking to deploy a good vulnerability scanner, or those interested in replacing their current scanner with something better and more capable.
On a personal note, let me wish all my readers and their families a happy holiday, with plenty of quality leisure time and good eats. I’m off shortly to pick up a brined Kosher turkey, and expect wonderful results when it emerges from the oven tomorrow afternoon.
I’ve grappled with this problem on various Vista systems for over a year now. A user will be tooling along merrily in Vista on his or her desktop when all of a sudden BAM! Explorer.exe crashes, and automatically restarts itself. A look into the Event Log on the affected desktop usually produces an Event 1000 Error, with the following General log entry:
Faulting application Explorer.EXE, version 6.0.6001.18000, time stamp 0x47918e5d, faulting module unknown, version 0.0.0.0, time stamp 0×00000000, exception code 0xc0000096, fault offset 0x027262f3, process id 0xc44, application start time 0x01c94d7badff6da6.
The two keys to unraveling this problem are the identification of Explorer.exe (which your users will tell you about anyway) and the privileged exception error code 0xC0000096. If you research this history of this code along with explorer.exe, you won’t find much about it on Vista per se, but there are plenty of postings on this topic related to XP. Further digging reveals that file associations active inside Explorer, especially those that invoke non-Microsoft viewers (as when, for example, you designate WinZIP as the default tool for opening .ZIP files, or Paintshop Pro as the default for .jpg, .gif, and .png files) can sometimes cause delays in getting Explorer to open drive icons (it’s chasing viewers down to populate listings with thumbnails in case you wonder why this happens), and can also cause occasional, apparently random crashes as various activities you undertake cause Explorer to refresh views of a drive or folder.
There’s a nifty little freeware program available from Nirsoft called ShellExView that will show you all of the Shell Extensions installed on Windows Vista (and thus also, part of Windows Explorer). By carefully disabling third-party (non-Microsoft, that is) shell extensions inside Explorer–especially those your users never touch, and therefore don’t need anyway–you can usually stop these problems dead in their tracks. When you see how many file extensions appear on a typical desktop (the one shown has 341 shell extensions installed, of which just over 30 come from third parties, and the rest from Microsoft) you’ll develop a profound appreciate of how the occasional tangle here could easily cause problems.
The accepted technique for troubleshooting such issues is to start by disabling all non-MS shell extensions, then re-enable third-party entries in vendor-specific groups to isolate the offending party or parties. My experience has been that you can disable those that aren’t used without any difficulty, then concentrate on those that are used. I’ve been able to identify the culprits in most cases by doing away with unused shell extensions, and have never had to spend more than 15 minutes running down other culprits.
Try it: you’ll find ShellExView to be a very useful tool.