While working on  Bumble Beegger we came across a daunting problem that only seemed to happen under certain conditions.

Silverlight error message
ErrorCode: 4002
ErrorType: ManagedRuntimeError
Message: System.Exception: Error HRESULT E_FAIL has been returned from a call to a COM component.
at MS.Internal.XcpImports.MethodEx(IntPtr ptr, String name, CValue[] cvData)
at System.Windows.DependencyObject.MethodEx(String methodName, CValue[] cvData)
at System.Windows.UIElement.ReleaseMouseCapture()
at System.Windows.Controls.Primitives.ButtonBase.ReleaseMouseCaptureInternal()
at System.Windows.Controls.Primitives.ButtonBase.OnLostFocus(RoutedEventArgs e)
at System.Windows.Controls.Primitives.ButtonBase.OnLostFocus(Object sender, RoutedEventArgs e)
at System.Windows.CoreInvokeHandler.InvokeEventHandler(Int32 typeIndex, Delegate handlerDelegate, Object sender, Object args)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, String eventName) 

After a few hours of debugging, experimenting and googling I came across a discussion on Silverlight.net that shed some light on the problem.

As it turns out there is bug in Silverlight 2 beta 1 that can cause a crash when changing the visibility of a button control inside a mouse event handler.

The recommended workarounds around this problem were to change the size to 0,0 or change the opacity to 1.

Another option is to use the Canvas.ZIndexProperty and set it to a number that is smaller then your foreground elements.

The problem is that those does not always produce a similar enough effect in other elements.

If you still want to use visibility where possible, you can check the type of control and choose to modify visibility, size, opacity or Z Index according to the type.

Granted this is a horrible hack but it gets the job done until we can get our hands on beta 2...

Example:

If you are trying to debug ASP.NET applications on Vista you might run into the following problem:

localhost is not accessible through your browser and the error that is displayed is "Internet Explorer cannot display the webpage".

After some googling I ran across a reference to the same problem.

The problem has to do with the fact that there are 2 entries for local host in the hosts file ([Windows directory]\System32\drivers\etc\hosts).

One for ipv4 and one for ipv6.

Example:

127.0.0.1 localhost
::1 localhost

To solve the problem you can remark one of them. The example below remarks the ipv6 entry.

127.0.0.1 localhost
# Causes problems when using localhost ->
#::1 localhost

Note that you might not be able to modify the hosts file even if you are running as an administrator.

The following Microsoft KB explains how to change the hosts file:

http://support.microsoft.com/default.aspx?scid=kb;en-us;923947

Hope this helps...
 

Last week we were trying to debug legacy 32-bit applications that were misbehaving on Windows 2008 64-bit.

Microsoft's debugging tools for windows information page states the following regarding When to Use 64-bit Debugging Tools.

"The 64-bit versions of Debugging Tools for Windows allow you to debug both 32-bit and 64-bit user-mode applications running on 64-bit processors. Use this package to debug both the application and the WOW64 emulator."

Unfortunately WinDbg 64-bit does not seem work properly on at least some of the 32-bit apps running on windows 2008 64-bit that we have tested.

The problem is that WindDbg does not seem to find the correct symbols for the 32 bit application you try to debug even though WinDbg finds the correct PDB symbol files.

To solve the problem we had to install the 32-bit version of the debugging tools for windows side by side with the 64-bit version (we did not have to uninstall the 64-bit version) and use the 32-bit version to debug the 32-bit applications running on the 64 bit version of windows. 

Note that the version of the debugging tools for windows we used for both 32 and 64 bit debugging was version 6.8.4.0 released on October 18, 2007.