Vanilla WPF application hangs on one customer's machine

At a customer, one of our WPF applications started to hang. When trying to reproduce the problem with a minimal working example, I discovered that even the most basic (non-trivial) WPF application will hang on that machine.

Example A: Create a new C# WPF project in Visual Studio 2008. Change nothing, compile it and run it on the customer's machine. It will run.

Example B: Take Example A, and add a TextBlock to the main form Window1:

<Window ...>
    <Grid>
        <TextBlock>Test</TextBlock>
    </Grid>
</Window>

Compile the application and run it on the customer's machine. It will hang: The title bar and the window border is visible, the inside is transparent and the window does not react to anything (cannot be moved or closed). The application must be shut down using the task manager.

Obviou开发者_开发百科sly, this customer's WPF is broken. Is this a known issue, i.e., has anyone encountered it before and already knows how to solve it (e.g. reinstall .net 3.5 SP1, etc.)?

The development machine is W7SP1, the customer's machine is XP (probably SP3, didn't check).

Check out Tom Dudfield's instructions to clear the WPF font cache. It's worked for me for several users.

Also, I recently had this experience in a more complicated example.

FLAILING:

I tried this cleaning the font cache thing and it did nothing for my hanging application, but YMMV. Nevertheless it seems harmless.

Also tried NGEN'ing all the framework stuff but that did not resolve the problem.

SOLUTION:

In my MVVM app, I have an ItemsControl (generic, not a real ListBox) on a complex control dropped on a tab page. The ItemsControl presented about 14 'data rows' consisting of custom controls bound to a small collection, which itself was surrounded by a ScrollViewer. With the ScrollViewer surrounding, selected computers would thrash endlessly and get stuck. Commenting out the Xaml made the app behave totally OK which pretty much ruled out problems in the backing ViewModel.

Removing the surrounding ScrollViewer eliminated the problem and it was not really necessary anyway. I do suspect that the real problem lurks in a style somewhere but frankly did not have time or patience to investigate further...

Fragment

<!--<ScrollViewer ScrollViewer.VerticalScrollBarVisibility="Auto"
                  ScrollViewer.CanContentScroll="True" Grid.Row="7" -->
    <ItemsControl   Grid.Row="7" 
            VerticalAlignment="Stretch"    
            HorizontalAlignment="Stretch"
            Name="FileSettingsList"  
            ItemsSource="{Binding MigratorFiles.FilesCollection}"   
            BorderThickness="2"                          
            HorizontalContentAlignment="Left"
            Template="{StaticResource   FileNameSettingsItemsControlTemplate}"                          
            ItemsPanel="{StaticResource FileNameSettingsItemsPanelTemplate}" 
            ItemTemplate="{StaticResource FileNameSettingsItemDataTemplate}"  >
    </ItemsControl>
    <!-- /ScrollViewer -->