Martin Zugec blog : Compatibility

Map external drive to local folder

martin — Sun, 30 Mar 2008 13:17:00 GMT

As mentioned before, I bought new desktop - and with new computer, there comes usually new challenges.

My new PC have built-in card reader - but as you know, if you have card reader with NO media inside, it will still occupy your drive letters and this can be quite confusing. Specially because I am using external USB drive and I am used that it is mapped to drive E: on my laptop - on desktop it is drive J:

So I decided to use some less known functionality of Windows - to map disks to local folders instead of drive letters. To achieve that, you have to follow these steps:

1.) Create some local folders - I created C:\Links (which is my storage of symlinks shortcuts) and there I created folder ExternalHDD

2.) Right click on Computer and select Manage

3.) Select Disk Management

4.) Right click on selected disk, select Change Drive Letters and Paths

5.) Remove current drive letter:

6.) Click on Add. Instead of specifying new drive letter select "Mount in the following empty NTFS folder" and specify folder you created in step 1:

7.) Click OK

Now you can check that your external HDD is no longer available through drive letter, but it is instead mapped to your local drive :)

I also created C:\Links\CardReaders - and I am mapping all my (empty) card readers as folders (so SD will be SD, MMC will be MMC etc...) to better organize my stuff:

So here is after all my final picture from Computer:

I really like to use symlinks to organize my data and to make them easily accessible. Microsoft is also using symlinks - and this is one of examples where you can run into hidden implementation of symlinks.

UPDATE: Forgot to mention - it is NOT Windows Vista specific feature, it definitely works on Windows XP and probably on Windows 2000 (I am using this feature for looooooong time)

How to detect if library requires registration II.

martin — Mon, 10 Mar 2008 10:08:00 GMT

As you maybe noticed, I released small utility that allows you to detect all libraries (dlls or ocxs) that requires registration using RegSvr32 and can potentially lead to DLL hell (and are very dangerous in SBC environments, specially with strong NTFS security)...

In this utility I am using LoadLibraryA API to load library and then try to detect existance of DLLRegisterServer function. Problem is that this API is too "intelligent" - it is not really silent and sometimes it will popup some message box like "This application has failed to start because xxx.dll was not found. Re-installing the application may fix this problem.". LoadLibrary requires also all dependent libraries to be loaded successfully and that is why such messages are returned.

Because there is nothing I can do about this error and COMDetector is command line tool that should be used for parsing, I decided I must found another way how to detect such files. Another approach was to detect OLESelfRegister. After some investingation I found that this is present as part of the Version information, so I tried to have a look through normal GUI and voila - to my surprise this information is really there :)

So (if you want to do it quickly) easiest way how to detect if DLL\OCX requires registration is to right-click on such file, select Properties, Version and locate OLESelfRegister - if it is there, you must register such component (or generate manifest as I wrote in another article).

Right now I am rewriting COMDetector to implement this new scan technique, I am also adding switch for recursive scanning. If you want to request any additional functionality, just let me know.

System.OutOfMemory and random errors

martin — Thu, 28 Feb 2008 15:40:00 GMT

One of my (read "created by me") programs suddenly stopped working - to my surprise, for everyone else everything was working flawlessly - except me...

It was giving me range of random errors (most common was System.OutOfMemory), even when I run it through debugger, it was crashing on random lines with really strange errors (psadi.dll was not found...)... That was really strange. And it was really strange that all other .NET applications were working fine. Most of the time System.OutOfMemory was throwing when reading 5 text files (all of them contained 1 line of text) - come on, we are not in middle age, modern computer should be able to handle it ;)

For all my applications (and many of my project) I really love to use Subversion - if you dont know it, drop me line and I will write some details about it.. I decided to revert to older version of application.

Because I also wanted to keep my current version, I saved file under different file name - and tadaaa - it was working flawlessly again. Then I tried to rename also my latest version - and now it was running smoothly. So I checked HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options - this is the key where all debuggers etc are hooking to application processes (including my tool Hook Application)...

To my surprise MyApp.exe contained tons of subkeys with strange names like DangerousAPIs, Locks etc... I tried to rename this registry key - and application was working..

After small investigation I traced the root of problem to Application Verifier - and then I remembered that this week I had presentation where I showed also AppVerif - and I was presenting on my program.

To make long story short - if your application works after you rename main exe, check Image File Execution Options registry key and maybe it will help you.

New utility to detect COM objects

martin — Sun, 17 Feb 2008 00:30:00 GMT

If you are deployment specialist or responsible for deploying applications AND keeping computers running afterwards, I think you agree that you always want to know what will installer do - therefore you prefer to use copy and paste installations...

Even if that is not applicable and you are like me, you rather build your own script to copy folders\files and register some libraries instead of using some installer (or maybe you are not and I am really, really strange ;)).

If you do so, then you probably encountered situation when you can see tens or hundres of DLLs in one folder and you are not sure which are static and which requires registration through regsvr32. Or you can run into situation when application suddenly stopped working and you are almost sure that it is due missing registration of one file.

I run few times into this situation - and I decided to write small utility that is able to detect libraries that requires registrations... It is called COM Detector ;)

It is really easy to use it - just specify file or folder as input parameter and it will show you if file\files are COM objects (and requires registration prior to use) or they are not.

This is output when scanning System32 folder (only few lines to show you):

bios4.rom:Not DLL or OCX file
bitsprx2.dll:COM
bitsprx3.dll:COM
blackbox.dll:COM
blastcln.exe:Normal library
bootcfg.exe:Normal library
bootok.exe:Normal library

You can see that bisprx2.dll, bitsprx3.dll and blackbox.dll are COM-based so you must register them in order to be able to use them.

To simplify parsing, delimiter is ":" - this is selected due to fact that you can`t use ":" in file\folder name because it is used for alternative data streams.

There are two optional switches available, /Debug and /SkipNoCOM. /Debug is used for debugging and is not really important, when you specify /SkipNoCOM, only COM objects will be displayed.

Also known bug - if you encounter message box like "The application or DLL <File> is not a valid Windows image. Please check this against your installation diskette.", just ignore it - it is displayed by API and (so far) there is nothing I can do about it.

FileMon, RegMon... What about LibMon?

martin — Fri, 15 Feb 2008 10:43:00 GMT

Recently I wrote small article about DLL Hell problem (http://msmvps.com/blogs/martinzugec/archive/2007/11/11/dll-help-is-there-any-solution.aspx).

Maybe you were also experiencing similar problems and you tried to use some tools to troubleshoot - best choice is usually FileMon\RegMon (or ProcMon), but usually they wont really help when working with libraries. This is specially case with legacy Visual Basic 6.0 applications, that just crashes with general error (Library not found).

And maybe you also encountered tool called Dependency Walker (www.dependencywalker.com) from Microsoft. This is quick summary from website:

"Dependency Walker is a free utility that scans any 32-bit or 64-bit Windows module (exe, dll, ocx, sys, etc.) and builds a hierarchical tree diagram of all dependent modules."

Maybe you also tried this utility - just to find out that it is quite useless, because most libraries (99%) are loaded dynamically and are not listed in tree view (usually you only see base system libraries):

Just by accident I found that new (silently released) version contains also functionality called Profiling (dont ask me why they choose such meaningless name instead of Monitoring or any other option).

This option allows you to run program and detect dependencies automatically (Profile -> Start Profiling). Of course output is much more detailed now:

Also attached log file can be extremely useful when troubleshooting:

LoadLibraryExW("C:\Apps\Opera 9\Microsoft.Windows.Common-Controls.DLL", 0x00000000, LOAD_LIBRARY_AS_DATAFILE) returned NULL. Error: The system cannot find the file specified (2).

in above example, application I used was downloaded from ThinDownload - obviously during packaging they forget something, because I dont have C:\Apps.
I already used this tool few times and it can be extremely useful. For example when I noticed that one library is always returning something like Error: The specified procedure could not be found (127)., I knew that problem is not caused by missing library, but due to version mismatch.