2013-07-04 15 views
8

Microsoft Ribbon for WPF(またはこれに接続されたものの組み合わせ)を使用すると、コンピュータが大規模で複雑なデスクトップアプリケーションにいくつかの問題が発生しました。ハング。このWPFリボンアプリケーションでWindowsがハングアップする原因

以下のコードは、いくつかのコンピュータでWindowsがハングする状況を引き起こしているようです。一部のコンピュータでは毎回このハングアップが発生しますが、一部のコンピュータではこれが発生しません。ハングすると、一部のコンピュータではセッション全体がロックされます(num lockとcaps lockを含む)が、マウスはまだ動きます(num lockはまだビジネスから外れています)。コンピュータが応答しなくなると、リモートログオンやネットワーク共有のように見えますが、コンソールセッションを終了することはできません。

  • マイクロソフトリボンWPF
  • WindowsはElementHost
  • でWPFコントロールをホストするフォームアプリケーション用:要するに

    は、何が行動の根本的な原因は、いくつかの組み合わせであるように思わ

  • WPFリボン上でレンダリングソフトウェアの
  • 使用(CreateParamsを使用することによって)ダブルバッファリングWindowsフォームの使用

私たちは後ほどいくつかの選択されたフォームでWS_EX_COMPOSITEDを使用してこの問題を解決しましたが、この問題の根本原因を明らかにしたいと思います。

私はハングを再現するための簡単な方法をまだ発見していませんが、この最小限のアプリケーションは、少なくとも一部のマシンでは、マウスを最大限に復元/リボンボタン。

次のコードは、Microsoft WPF Ribbon .NET 4.0ライブラリに対して、x86 .NET 4.0としてコンパイルされています。

using System; 
using System.Windows.Forms; 
using Microsoft.Windows.Controls.Ribbon; 
using System.Windows.Interop; 
using System.Windows.Forms.Integration; 

namespace WindowsRibbonHang 
{ 
    public class Form1 : Form 
    { 
     protected override CreateParams CreateParams 
     { 
      get 
      { 
       CreateParams cp = base.CreateParams; 
       cp.ExStyle |= 0x02000000; // Turn on WS_EX_COMPOSITED 
       return cp; 
      } 
     } 

     public Form1() 
     { 
      Ribbon ribbon = new Ribbon(); 

      RibbonTab tab = new RibbonTab { Header = "FooTab" }; 
      ribbon.Items.Add(tab); 

      RibbonSplitButton button = new RibbonSplitButton { Label = "FooButton" }; 
      tab.Items.Add(button); 

      ElementHost elementHost = new ElementHost 
      { 
       Dock = DockStyle.Fill, 
       Child = ribbon, 
      }; 

      Controls.Add(elementHost); 
      Dock = DockStyle.Fill; 

      ribbon.Loaded += (sender, args) => { 
       HwndSource hwndSource = System.Windows.PresentationSource.FromVisual(ribbon) as HwndSource; 
       HwndTarget hwndTarget = hwndSource.CompositionTarget; 
       hwndTarget.RenderMode = RenderMode.SoftwareOnly; 
      }; 
     } 
    } 

    static class Program 
    { 
     /// <summary> 
     /// The main entry point for the application. 
     /// </summary> 
     [STAThread] 
     static void Main() 
     { 
      Application.EnableVisualStyles(); 
      Application.SetCompatibleTextRenderingDefault(false); 
      Application.Run(new Form1()); 
     } 
    } 
} 
+0

この問題を解決しましたか?私はこの問題とこの他の1つだけを見つけることができましたhttp://stackoverflow.com/questions/7719627/wpf-elementhost-in-winforms-crashes-windows-when-maximizedこの問題についてはどちらも解決策を見いだせませんでした。 –

+0

@EduardoWadaそうではありません。 @Ollyが述べたように、これはおそらくWPFがグラフィックスドライバとやり取りする方法と関係しているはずです。 "解決策"は、 'CreateParams'オーバーライドを無効にして、代わりによりターゲットを絞ったフォームで行うことでした。 – torkildr

答えて

1

影響を受けるコンピュータのグラフィックドライバが最新であることを確認してください。 WPFは伝統的なGDIコードとはまったく異なる働きをするため、信頼性の低いドライバでは、あなたが説明するような種類の問題を引き起こすことがあります。

+0

私はそれがグラフィックドライバ関連かもしれないと考えています。興味深いのは、それが複数のグラフィックスカードベンダーで起こっているように見えることです。私はあなたが示唆したように、最新のグラフィックスドライバにアップデートしようとしました。 – torkildr

1

この問題は、複合Windowsで発生しています。私は、問題をさらに分析し、OSに関連する問題のようだ:

The Case of Slow WPF Rendering in a WinForms Application

2つのスレッドが一つのスレッドに複合Winformsのウィンドウがレンダリングとのループでお互いのウィンドウをレンダリングし、無効にしてみてくださいを参照してください。もう一方のスレッドは、WPFレンダリングスレッドは同じことを行います。これは、ソフトウェアのレンダリングが有効である限り、Win 7 - Win 10マシンで発生します。

WPFまたはWinFormsが暗黙の契約に違反しているかどうか、またはそれが明白なDWMバグであるかどうかは、MSの専門家のみが教えてくれるDWM(デスクトップウィンドウマネージャ)のようです。