Interop.ComAdmin exception when using IIS on a 64-bit OS

If you install IIS on a 64-bit operating system, you may get the following error when navigating to your website locally:

Could not load file or assembly ‘Interop.COMAdmin’ or one of its dependencies. An attempt was made to load a program with an incorrect format.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.BadImageFormatException: Could not load file or assembly ‘Interop.COMAdmin’ or one of its dependencies. An attempt was made to load a program with an incorrect format.

The clue here is the BadImageFormatException, which hints that this is a 32/64 bit issue. To fix it, in IIS Services Manager, go to Application Pools, select the application pool under which your website/application is running, and choose ‘Advanced Settings’. Change ‘Enable 32-bit Applications’ from False (the default) to True. Recycle your app pool, and reload your browser page, no more error!

Pairing SPP bluetooth devices with Android phones

Update: I have turned the below class into an app which I’ve made available in the Google Play Store called Bluetooth Class Zero. It is a simple application which just enables pairing with bluetooth class zero devices without having to root & patch your phone.

————————————–

I bought a Bluetooth Bee from Seeed Studios, which is an SPP (Serial Port Profile) bluetooth device, with the intention of writing an app for Android that communicates with a remote data logger. Unfortunately, it turns out that there’s a bug in the BroadComm bluetooth stack that is used by most Android phone manufacturers (LG, HTC, Samsung are affected, but not the Google Nexus phones) that prevents discovery to this and all other bluetooth devices that report their Class of Device (CoD) code as 0x00. This is the case for many SPP bluetooth devices, and SPP is probably the most common bluetooth profile (at least it’s the most basic – just straight serial comms) so this bug is pretty nasty.

Basically, if you perform a scan for devices, your SPP device will not show up, and in the logs you will see:

ERROR/DTUN_HCID4(663): Device [00:18:E4:0C:6E:CA] class is 0x00 – skip it.

The code for the Broadcom bluetooth stack is open source, so the bug is plain for all to see here. The bug has been reported on StackOverflow and elsewhere.

Until Broadcom and/or all users of their bluetooth stack fix this issue (by simply removing the IF block that skips devices whose CoD is 0x00), the only way to connect to your SPP device from Android is to read the log files, looking for the above error, extract the device address, and manually initiate a connection in code. After this, your SPP device will appear along with all your other bluetooth devices in the bluetooth settings page on your phone, and you can successfully communicate using the bluetooth API provided by Google.

I have written a re-usable class that implements this workaround, which you can download from here.

How to use (from your Activity class):

(new BluetoothClassZeroDiscoveryTask(
    this, 
    new BluetoothDiscoveryCallback())).execute();

Where BluetoothDiscoveryCallback is a class defined e.g. in your Activity. The call method will be called after the discovery task completes, and is passed the complete list of paired bluetooth devices, including those that are undiscoverable due to the above bug.

private class BluetoothDiscoveryCallback
    implements Action<ArrayList<BluetoothDevice>>
{
	public void call(ArrayList<BluetoothDevice> devices)
	{
		// Now you have the list of ALL available devices, 
		// including those that report class 0x00.
	}
}

// Java equivalent of the built-in Action from C#.
public interface Action<T>
{
	void call(T target);
}

You’ll also need to add READ_LOGS permission to your manifest file:

<uses-permission android:name="android.permission.READ_LOGS" />

Feel free to suggest improvements to the code, I’m new to Android and haven’t done Java in ages 🙂

P.S. Hassle your phone manufacturer to fix this bug so this workaround is not needed!

App Screenshots:

After pressing “Start Discovery”, if any bluetooth class zero devices were found (but ignored), you will get the standard pairing dialog:

After entering the correct PIN code, your device will be listed alongside others in your bluetooth settings:

The app requires Android 2.1+. It’s been tested on the following phones:


Manufacturer Model Android Version Affected Results
LG Optimus One 2.2 Yes Works
HTC Desire HD 2.2 Yes Works, but unfortunately may interfere with networking / bluetooth operation.
Samsung Galaxy S (I9000) 2.2 Yes Fails
Samsung Galaxy Player 50 2.1 Yes Works

The app is free to use, if you find it useful, feel free to make small donation 🙂

PicasaPhotoViewer.exe staying in memory

Google’s Picasa Photo Viewer is one of the best photo preview applications, it loads quickly, and is easy to exit. Unfortunately, Google introduced a bug recently that causes the PicasaPhotoViewer.exe process to remain in memory even after you close the application. Several posts on google forums and elsewhere have reported this:

Why does PicasaPhotoViewer.exe stay resident in memory
Multiple picasaphotoviewer.exe ghosts in Task Manager
Memory Loss from orphaned PhotoViewer Processes
PicasaPhotoViewer Process Doesn’t Terminate

This appears to only occur when you open a photo on a network location, such as a network drive. This is a pretty normal usage scenario, such as storage of photos on a RAID server or NAS, and is actually pretty nasty, because it means you can’t rename/delete/move any directory in which you viewed an image including any parent directory (due to the still-running PicasaPhotoViewer.exe locking the directory). It doesn’t take long for this to get seriously annoying when you find yourself having to open Process Explorer/Task Manager to kill off all the orphaned PicasaPhotoViewer.exe processes when you are working with directories.

Orphaned PicasaPhotoViewer.exe processes.

Until Google fixes this, I solved this with a small C# application. It monitors for orphaned instances of PicasaPhotoViewer.exe (i.e. those that are running but have no window) and kills them. This is the complete code:

static void Main(string[] args)
{
   while (true)
   {
      var picasaProcesses =
         (from p in Process.GetProcessesByName("PicasaPhotoViewer")
          where p.MainWindowHandle == IntPtr.Zero && !p.HasExited
          select p);

      foreach (var process in picasaProcesses)
      {
         process.WaitForInputIdle();
         if (process.MainWindowHandle == IntPtr.Zero)
         {
            process.Kill();
            process.WaitForExit();
         }
      }

      Thread.Sleep(1000);
   }
}

Feel free to download the utility, and launch it on Windows startup using a logon script such as described here. Note: The program requires admin rights to run, so you can’t just place a shortcut to it in your ‘Startup’ folder if you are using Vista/7 with UAC switched on.

Update: Ok, it appears this issue has been fixed by Google in Picasa build > 117.38. Updating to the latest version (build 117.43 at the time of writing) fixed the issue for me, so my program should no longer be needed 🙂

Update 2: According to the comment below, the issue may still be occurring for some people. So I have made the program to fix this available for download again.