Lee Feigenbaum: Computer Information

Now having done Windows development for over two years, I've found that having the Windows debug symbols for common Windows DLLs installed (properly!) on my system has been a great aid in debugging difficult crashes with otherwise unhelpful stack traces. It also lets you see fun DLL function names like RecvLotsaCallsWrapper. Jordi has compiled information from Elias, himself, and me to put up a page on how to setup Microsoft Debug Symbols Server for use with MsDev.

I often find myself confusing regular expression syntaxes from the various systems I use regularly. Hopefully this chart will help, though it does not intend to be near-exhaustive (especially for a system like Perl's):

	Quantifiers	Tagged Grouping / Backreference	Alternation	General / Shortcut Character Classes	Anchors	Other
Perl	* + ? {0, 3} *?	(...) / $1, $2, ...	\|	[...], [^...], ., \w, \d, \s	^ ... $	Lots.
Visual Studio 6	* +	$...$ / \1, \2, ...	\!	[...], [^...], ., \:c, \:a, \:d, \:h(ex)	^ ... $	Shortcuts for string literals, identifiers, integers
Vim (magic)	* \+ \? \{0, 3} \{-0, 3}	$...$ / \1, \2, ...	\\|	., \w, \d, \s, \x, \i, ...	^ ... $	Plenty (identifiers, keywors, zero-width, ...)
.NET	* + ? {0, 3}	(...) / \1, \2, $1, $2	\|	., \w, \s, \d	^ ... $	Lots.

The libwin32 distribution must be patched to find the DLLs needed to successfully make and use the Perl libraries. The patch and instructions for applying the patch can be found in this Cygwin mailing list message. The patch there may or may not work better than the patch linked to here. The latest version of cygwin's w32api package includes the two functions TerminateJobObject and AssignProcessToJobObject, and so these must also be commented out in the libwin32 Job.xs. Next, the ocidl.h file included in the current version of the Cygwin w32api seems to be missing the GUIDKIND enum that causes OLE.xs to fail to compile correctly. I fixed this by adding the following to the cygwin /usr/include/w32api/ocidl.h:


typedef 
enum tagGUIDKIND
    {   GUIDKIND_DEFAULT_SOURCE_DISP_IID    = 1
    }   GUIDKIND;

I have since had rebasing issues with some of my hand-installed Perl modules. This can be fixed using the rebase tool. However, the rebaseall script distributed with the tool gets its file list from cygwin's setup catalog, which does not include DLL that are hand installed (in my case, this includes Image::Magic, Image::EXIF, and Win32::OLE - who knows what else?) Rebasing still solves the "unable to remap" problem, but needs to be done manually with commands such as:


   rebase -v -d -b 0x70000000 -o 0x10000 path/to/file.dll

Well, standard techniques include seeing how regular the error is, determining if any new drivers have been installed recently, etc. For the real annoying cases in which the errors are intermittent and there is no obvious cause, here's what I've done:

Use debugging tools for Windows (WinDbg) to analyze the minidump files created by the crash. These .dmp files are stored in the c:\windows\minidump directory. After loading a crash dump, try running !analyze -v to see if the stack trace gives any clues.
Setup the Windows special pool feature. See this MS Knowledge Base article (188831)
I next stumbled upon a knowledge base article about Microsoft's Driver Verifier tool. This tool allows drivers to be monitored on a per-driver basis. When I ran the tool and aksed it to verify all unsigned drivers it found, I immediately got a BSOD on restart. By enabling verification on a few drivers at a time, I was able to narrow the problem down to a single driver. In my case, I was able to just uninstall the program that used that driver, but in other cases, the problem driver might need to be upgraded.

Aside from state changes, the most common cause of this that I've found is when parameters are not quite identical. In particular, sending a wide string (LPOLESTR) when a BSTR is expected may work if the string is only ever displayed, but if, for example, it's length is taken, then this will not work. Thus one call to such a method with a wide string literal (L"my string") may fail, while the same call with the same string put into a BSTR will succeed. Note that one particularly gotcha example of this is when the string argument is marshalled. In this case, the marshaller takes its length implicitly, and so passing a not-really-a-BSTR will definitely fail with unpredictable results.

This problem occurs when your default browser is something other than Internet Explorer. In my case, my browser is Firefox. To fix this problem, go to the "File Types" tab in the "Folder Options" dialog (reachable from Control Panel or Windows Explorer). Find the entry for URLHyperText: Hypertext Transfer Protocol, and click "Advanced". Click "Edit" and make sure that the "Application:" field reads "FIREFOX". (In my case, it erroneously read "IEXPLORE".) This should solve the problem.

Fortunately, the answer to this odd bug is the same as the answer to the previous question. So follow those instructions.

In my case, the eventual problem was a missing registry value. Under the registry key HKEY_CLASSES_ROOT\PROTOCOLS\Handler\mhtml, I had an empty CLSID entry. Filling in the data: {05300401-BCBC-11d0-85E3-00C04FD85AB4} to go with the CLSID name fixed the problem. For good measure, ensure that the default value for that key is MHTML Asychronous Pluggable Protocol Handler. Note that if you're receiving these symptoms with a file with a .eml extension, then you probably just need the solution from this Microsoft Knowledge Base article.

Check out the code at this codeguru article. The basic idea is that you have to create the image list with the proper color flags (eg ILC_COLOR32) before adding the bitmaps to it.

To do this, I needed to edit the gem's specification. I found it at: /usr/lib/ruby/gems/1.8/specifications/rdf-redland-0.5.1.3.gemspec i edited it and changed the autorequire value from rdf to rdf/redland. My distribution of rdf-redland does not contain an rdf.rb file, so I made it require the next (looking) best thing: lib/rdf/redland.rb. We'll see if it works.