Thanks, eh.

After double-checking file system permissions, and running Filemon to try and figure out where stuff was failing, I found out that the task scheduler actually creates a log file. By default it seems to live at %SystemRoot%\Tasks\SchedLgU.Txt, but that location can be changed in the registry by modifying the LogPath value at HKLM\SOFTWARE\Microsoft\SchedulingAgent.

That log file contained an error message (well, several...) that quickly lead me to Microsoft Knowledgebase article KB867466. Turns out that on Windows Server 2003 member servers, non-admin users running non-interactively don't have Read or Execute permissions to cmd.exe...

After fixing the permissions, the job ran fine.

That's when I discovered that the batch file was making some assumptions w.r.t. the user's regional settings, so I switched to a VBScript instead. If I'd done that in the first place, I wouldn't have had to spend 15 minutes fighting with the task scheduler, since the permissions issue doesn't apply to cscript.exe...

Oh well.

Usually I just use ping -t -n count host for this, but I was also thinking that it would be nice to be able to terminate the process before the timeout. Not sure exactly how I came across it, but somehow I found waitfor.exe lying around in my system32 directory.

WAITFOR uses a mailslot to wait on or send a signal to. The waiting and sending can happen on the same machine, or the signal can be sent across the network.

In one command prompt, you perform the wait:

C:\\> WAITFOR /T 42 SignalName

In another, you send the signal:

C:\\> WAITFOR /SI SignalName

Way nicer than the old-fashioned approach of having process A poll a directory until process B has created a particular file. And, no less important, if the signal is not received within the specified timeout, you get:

C:\\> WAITFOR /T 1 Godot
ERROR: Timed out waiting for 'Godot'.

C:\\>_

:-)

When I found out about this limitation, I was actually encountering stack overflows in REGEDIT. However, shortly afterwards I wasn't able to reproduce that behaviour, so I considered it to be some fluke and just wrote about the limitation itself.

However, today I managed to overflow REGEDIT's stack again by just having it export a deep hierarchy to .REG, and this time I captured a crash dump:

0:000> kb 300
ChildEBP RetAddr  Args to Child
0004308c 77f60938 000002b8 00000000 000430b8 ADVAPI32!LocalBaseRegEnumKey+0x13
000430c4 0100bb37 000002b8 00000000 00043654 ADVAPI32!RegEnumKeyW+0x8c
00043890 0100bb08 000002b8 000438a0 004b0048 regedit!PutBranch+0x124
0004404c 0100bb08 000002bc 0004405c 004b0048 regedit!PutBranch+0xf5
00044800 0100bb08 000002c0 00044810 004b0048 regedit!PutBranch+0xf5
00044fac 0100bb08 000002c4 00044fbc 004b0048 regedit!PutBranch+0xf5

       ... Removed 190 lines that all end in regedit!PutBranch+0xf5

0007f1d4 0100bb08 00000578 0007f1e4 004b0048 regedit!PutBranch+0xf5
0007f458 0100bb08 0000057c 0007f468 004b0048 regedit!PutBranch+0xf5
0007f6c8 0100be1b 80000001 0007f6f0 00070e54 regedit!PutBranch+0xf5
0007f944 01006be3 0007f974 01059de0 00070e54 regedit!ExportWinNT50RegFile+0x16d
0007f958 01007272 00070e54 00000000 0007f974 regedit!RegEdit_ExportRegFile+0x2e
0007fb80 010062eb 00070e54 0000110a 7739c2ee regedit!RegEdit_OnCommandExportRegFile+0x65
0007fb98 01009751 00070e54 00000293 00000000 regedit!RegEdit_OnCommand+0x7f
0007fbbc 01009947 00070e54 00000293 000ad310 regedit!RegEdit_OnKeyTreeCommand+0xc4
0007fc24 010045ba 00070e54 00160c39 0007fc50 regedit!RegEdit_OnKeyTreeContextMenu+0x1a1
0007fc34 0100689f 00130dc2 00070e54 000002c4 regedit!RegEdit_OnContextMenu+0x2a
0007fc50 7739b6e3 00130dc2 0000007b 00070e54 regedit!RegEditWndProc+0x128
0007fc7c 7739b874 01006777 00130dc2 0000007b USER32!InternalCallWinProc+0x28
0007fcf4 7739c2d3 00000000 01006777 00130dc2 USER32!UserCallWinProcCheckWow+0x151
0007fd30 7739c337 00615210 00615118 00070e54 USER32!SendMessageWorker+0x4bd
0007fd50 7745b0ee 00130dc2 0000007b 00070e54 USER32!SendMessageW+0x7f
0007fd74 7745bcfc 00070e54 00000062 00000025 COMCTL32!TV_SendRButtonDown+0xad
0007fdc4 7739b6e3 00070e54 00000204 00000002 COMCTL32!TV_WndProc+0x616
0007fdf0 7739b874 7745b6e6 00070e54 00000204 USER32!InternalCallWinProc+0x28
0007fe68 7739ba92 00000000 7745b6e6 00070e54 USER32!UserCallWinProcCheckWow+0x151
0007fed0 7739bad0 0007fef8 00000000 0007ff1c USER32!DispatchMessageWorker+0x327
0007fee0 01009cb9 0007fef8 ffffffff 00000000 USER32!DispatchMessageW+0xf
0007ff1c 01016e04 01000000 00000000 000a24a6 regedit!WinMain+0x154
0007ffc0 77e6f23b 00000000 00000000 7ffdf000 regedit!WinMainCRTStartup+0x182
0007fff0 00000000 01016c82 00000000 78746341 kernel32!BaseProcessStart+0x23

If somebody wants to dive into the crash dump, let me know.

Exporting a deep key hierarchy on W2K8 X64 didn't work either, BTW:

I've been working on a tool that can export registry information in REGEDIT's .REG format. Since that format doesn't seem to be fully documented, I spent quite some time experimenting with REGEDIT. Here are some of my more interesting findings (all on W2K3).

No expansion beyond 32 levels
When you expand a key in REGEDIT, it passes the "root" HKEY (like HKLM) and the full path to RegOpenKey() instead of the immediate parent and just the name of the key you're trying to expand. This means that it will run into the "up to 32 levels at a time" limitation of the registry API:

No export beyond 200 levels
Although the registry supports 512 levels of keys, REGEDIT will only export upto a depth of about 200, silently ignoring anything beyond that...
Granted, that's not a very common scenario, but I would expect at least a warning message or something.

Importing values of non-existing types
WinNT.h defines 12 value types, ranging from REG_NONE (0) to REG_QWORD (11). REGEDIT however, will gladly accept all other 32-bit values as well...

[HKEY_CURRENT_USER\RegistryTest]
"Type Test"=hex(42):47,11

results in

Fiddler can act as a man-in-the-middle and decrypt SSL traffic, but then System.Net.Security rightfully complains about an invalid remote certificate ("The remote certificate is invalid according to the validation procedure."). This results in a System.Net.WebException "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.".

To prevent this from happening:

ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

Just be sure to not include this in production code :-)

• The build system needed to run a unit test of some code that depended on some COM object.
• That COM object was not installed on the build system (it wasn't a part of the system we were developing).
• Installing that COM object would mean having to install a large system with all kinds of dependencies — not exactly something I wanted to do on the build machine...

Fortunately, the interaction with the particular COM object was very basic. I made a fake implementation of it, just returning hard-coded responses for the few calls I needed. With the fake COM object in place, the unit tests passed.

I added some logic to the build file that checks whether a particular ProgID existed in the registry. If not, the build script registers the fake object, runs the specific tests, and then unregisters it again.
If the ProgID is found in the registry, however, just the tests are executed. This allows the build to be also run on a developer's machine containing the back-end system (and not mess up its COM registration). Works great.

Fast-forward to yesterday.

Triggered by a discussion with a co-worker about the fact that the unit tests aren't nicely isolated from the back-end system this way, I suddenly remembered reading about registration-free COM on Junfeng Zhang's blog.

Registration-free COM

As the name implies, registration-free COM makes it possible to use COM objects without registering them. An application gets all activation information (typelib, ProgID-to-CLSID mapping, threading model and the like) from a manifest file, instead of reading it from the registry. This allows multiple applications to use different versions of a COM object, with the same ProgID and/or CLSID.

That's a much nicer solution for my original problem — I no longer have to dynamically register and unregister my fake implementation, and I can use the fake implementation on systems containing the real one as well.

A sample manifest file

The manifest file I'm using looks like this:

<?xml version='1.0' encoding='utf-8'?>
<assembly manifestVersion='1.0' xmlns='urn:schemas-microsoft-com:asm.v1'>
  <assemblyIdentity type='win32' name='RegFreeCOM-sample.exe' version='1.0.0.0' />
  <file name='FakeTCMXML.dll'>
    <comClass clsid='{69c2082a-61b1-4a83-a947-88420fac54fa}'
              threadingModel='Apartment'
              progid='TCMXML.XMLResponder' />
  </file>
</assembly>

I've saved this as RegistrationFreeCOM.exe.manifest in the same directory as my test application RegistrationFreeCOM.exe, and also copied my fake implementation FakeTCMXML.dll into that directory. The test application will activate TCMXML.XMLResponder from FakeTCMXML.dll, regardless of whether that ProgID already occurs in the registry, and without affecting that registration.

Creating a manifest file

For many scenarios, the sample manifest file is sufficient: just update the 'name', 'clsid' and 'progid' attributes. You can find the value for 'clsid' in the IDL for your component, or by using OleView.
You can also have Visual Studio 2005 create a manifest file for you: create a throw-away project, reference your COM dll, view the properties of that reference, and toggle the 'Isolated' flag to 'True'. When you build the project, the manifest file will be generated.

(This post triggered by receiving a lovely screen dump of a message box. A message box covering almost the complete screen, and containing lots of serialized XML. XML containing lots of entitified HTML...)

In order to do this, change the line "WScript.Echo s" to "Echo s". In BGInfo, create a VBScript Custom field, by clicking "Custom...", "New...", selecting "VB Script file" and entering a field name and the path to your script.

Option Explicit
Dim cp, server, vmCollection, vmName, vm, s

Const vmErr_VMBusy = &H80040215
Const vmExecutionState_On = 1
Const vmExecutionState_Off = 2
Const vmExecutionState_Suspended = 3
Const vmExecutionState_Stuck = 4

Set cp = CreateObject("VmCOM.VmConnectParams")
Set server = CreateObject("VmCOM.VmServerCtl")

server.Connect cp
Set vmCollection = server.RegisteredVmNames

For Each vmName in vmCollection
   Set vm = CreateObject("VmCOM.VmCtl")
   On error resume next
   vm.Connect cp, vmName
   If Err.Number = vmErr_VMBUSY Then
      s = Basename(vmName) & ":      BUSY"
   ElseIf Err.Number <> 0 Then
      s = Basename(vmName) & ":     ERROR"
   Else
      On Error Goto 0
      s = vm.Config("displayName") & ": " & State2Str(vm)
   End if
   WScript.Echo s
next

Function State2Str(ByVal vm)
  Select Case vm.ExecutionState
      Case vmExecutionState_On
         State2Str = "       ON"
      Case vmExecutionState_Off
         State2Str = "      OFF"
      Case vmExecutionState_Suspended
         State2Str = "SUSPENDED"
      Case vmExecutionState_Stuck
         State2Str = "    STUCK"
      Case else
         State2Str = "  UNKNOWN"
   End Select
End Function

Function Basename(ByVal path)
   Dim pos
   pos = InstrRev(path, "\")
   If pos > 0 Then
      Basename = Mid(path, pos + 1)
   Else
      Basename = path
   End If
End Function

PUSHD to the rescue:

C:\\> pushd \\\\serendipity\\D$
Z:\\>

   Do something here with the files on Z:

Z:\\> popd
C:\\> _

PUSHD temporarily maps a drive letter to the specified UNC share (starting from Z: on down until it finds one that's available). Until you call POPD, you can access the share via that drive letter (also from other DOS boxes and Windows Explorer).

Sure beats mapping and unmapping shares all the time, but keep in mind that the PUSHD trick only works if you don't need to specify credentials to access the share.