Archive for January, 2008

I’ve been knocked off my sleep schedule this week — I had to test some sleeping medication I need for an upcoming business trip and verify that I wouldn’t have any unanticipated side effects before I was in Australia and unable to do anything about it. However, in the midst of all this, I had an interesting thought, spurred a discussion with my new office mate. We were talking about history and the traditional adage that “history is written by the winners.” I disagree; I think it’s something more like this:


History is interpreted by the winner’s descendants.

  • Share/Bookmark

Comments No Comments »

  • That I’ve managed to successfully get myself back on an “into work by 6am” schedule for nearly three weeks now. Even though I am not a morning person, I find that this schedule has a number of benefits, the most important being that I feel like I get more work done (of better quality) and that I correspondingly have an easier time keeping work from taking over my life.
  • Seeing that my sleep schedule is finally starting to show signs of settling down against the previous point.
  • Call of Duty 4.
  • Writing while listening to Def Leppard Pyromania and the Halo 3 soundtrack.
  • Having finally had the uninterrupted hour to clipper and shave my head again. True, it was at 3:30am this morning, but it just made a nice start to the day.
    • Share/Bookmark

    Comments No Comments »

    Yesterday, I ran into an interesting problem; I needed to give a small executable to a co-worker. However, this executable had simply been archived in a directory containing a wide variety of other programs, scripts, data files, and accumulated junk, and I really didn’t want to be overly generous by bestowing all of this detritus on my co-worker. Just to make things a little more complicated, the executable wouldn’t run by itself; it was a .NET application and had at least one, possibly as many as six, associated DLLs (I wasn’t sure how many and which ones because of the conditions under which I’d received the software).

    I went to one of our developers, and he told about the ildasm tool (Intermediate Language Disassembler) included with Visual Studio 2005. This tool does a lot of stuff, but you can also use the Manifest viewer to see what DLLs a .NET application requires. In order to run it, you need to start up a command line that has the necessary application path entries; the default command prompt does not have the Visual Studio directories added to its path. However, Visual Studio creates a separate command prompt shortcut for you: Programs, Microsoft Visual Studio 2005, Visual Studio Tools, Visual Studio 2005 Command Prompt.

    For whatever reason, this tool didn’t tell me what I needed to know. Just for fun, I tried opening a regular command prompt, copying my mystery executable (mystery.exe) to a temporary directory, and running it. As expected, it didn’t work and I got an error dialog box — but after I dismissed the error, I did get this intriguing response in my command prompt window:

    C:\temp\mystery.exe
    
    Unhandled Exception: System.IO.FileNotFoundException: Could not load file or ass
    embly 'missing, Version=1.3.3718.0, Culture=neutral, PublicKeyToken=null' or one
     of its dependencies. The system cannot find the file specified.
    File name: 'missing, Version=1.3.3718.0, Culture=neutral, PublicKeyToken=null'
       at STS.Mystery.Main(String[] args)
    
    WRN: Assembly binding logging is turned OFF.
    To enable assembly bind failure logging, set the registry value [HKLM\Software\M
    icrosoft\Fusion!EnableLog] (DWORD) to 1.
    Note: There is some performance penalty associated with assembly bind failure lo
    gging.
    To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fus
    ion!EnableLog].
     

    Okay, that’s pretty wicked cool: Windows, through the magic of the .NET framework, is telling me how to troubleshoot the problem. I can do this! I quickly fired up Regedit and added the following value:

    • Location: HKLM\Software\Microsoft\Fusion
    • Name: EnableLog
    • Type: DWORD
    • Value: 1

    With the proper registry value in place, I tried running my mystery executable one more time, and was rewarded with this:

    C:\temp\>mystery.exe
    
    Unhandled Exception: System.IO.FileNotFoundException: Could not load file or ass
    embly 'missing, Version=1.3.3718.0, Culture=neutral, PublicKeyToken=null' or one
     of its dependencies. The system cannot find the file specified.
    File name: 'missing, Version=1.3.3718.0, Culture=neutral, PublicKeyToken=null'
       at STS.Mystery.Main(String[] args)
    
    === Pre-bind state information ===
    LOG: User = DOMAIN\devin
    LOG: DisplayName = missing, Version=1.3.3718.0, Culture=neutral, PublicKeyToken=
    null
     (Fully-specified)
    LOG: Appbase = file:///C:/temp/mystery/
    LOG: Initial PrivatePath = NULL
    Calling assembly : Mystery, Version=0.0.0.0, Culture=neutral, PublicKeyToken=nu
    ll.
    ===
    LOG: This bind starts in default load context.
    LOG: No application configuration file found.
    LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2
    .0.50727\config\machine.config.
    LOG: Policy not being applied to reference at this time (private, custom, partia
    l, or location-based assembly bind).
    LOG: Attempting download of new URL file:///C:/temp/mystery/missing.DLL.
    LOG: Attempting download of new URL file:///C:/temp/mystery/missing/missing.DLL.
    
    LOG: Attempting download of new URL file:///C:/temp/mystery/missing.EXE.
    LOG: Attempting download of new URL file:///C:/temp/mystery/missing/missing.EXE.
    

    Sure enough, I had a single DLL I needed to locate: missing.dll. When I coped that DLL into my temporary directory and re-ran my application, I got the errors I expected to see from not providing the proper parameters.

    Problem solved! Now I could package up mystery.exe and missing.dll into a ZIP archive and send it along to my coworker.

    (If you use this, don’t forget to remove the EnableLog registry key when you’re done with it – otherwise, it can lead to performance issues for .NET applications. I would think you could set it to 0 to simply disable it, but the guidance I’ve seen says to actually remove it – so that’s what I did.)

    • Share/Bookmark

    Comments No Comments »

    It’s been a while since I’ve blogged much. There’s been a few reasons for that, but I just finished the lastest one last night. Yes, that’s right, our Christmas houseguest and I have been working back through Halo and Halo 2 in Cooperative mode in preparation for Halo 3. Last night, Chris and I finished Halo 3.


    WOW! Awesome game, great storyline. Anyone who says otherwise will be promptly ignored.

    • Share/Bookmark

    Comments No Comments »