問題タブ [wow64]

ここで述べたように、このコンポーネントはWindowsオペレーティングシステムの一部になりました。ただし、VB6ランタイムはWindows8以降ではサポートされていない場合があります。したがって、このコンポーネントもなくなる可能性があります（Windows OSの一部であっても）。間もなく、Interop.MSScriptControl.dllを使用してC＃コンシューマーを介してそれを利用しようとしています。私は何人かの人々がWindows7でそれに関して問題を抱えているのを見たことがあります。誰かがWindows7とWindowsServer2008 R2でそれを実行することに成功しましたか？誰かがそれがまだWindows8で動作すると思いますか？現在、64ビットシステムはWoW64を使用して使用すると考えて、x8632ビットCPU用にコンパイルしています。ありがとう！

更新：MicrosoftはまだWindows8.1でそれを修正していません。

編集：これはWOW64のバグであることが判明しました-スレッドがロングモードのリング3（ユーザーモード）で中断されると、GetThreadContext（）が古いコンテンツを返す場合があります。変換を実行するためにring-2を使用することをMicrosoftに提案しました。その場合、SuspendThreadはring-3のスレッドのみを一時停止し（現在のように-変更は必要ありません）、ring-2のクラッシュ/障害/エクスプロイトはカーネルに影響を与えません-ring-2とring-にのみ影響します3.3。

このような変更には、Wow64Get / SetThreadContextなどのいくつかのWinAPI関数の変更が必要になります。これにより、文書化されていない機能に依存するアプリが破損しますが、これは予想されることです。確かに、リング3からリング2に移行するのに数CPUサイクルかかるため、変換は遅くなります（CPUファミリによって異なります）が、正しい動作を保証するためには、OSの役割が何よりも重要だと思います。翻訳はすでにWOW64で実行されているアプリにオーバーヘッドを追加しているので、それも予想されます。

Microsoftがこの問題を修正することを願っています-そうでなければ、デバッガー/モノラルアプリ/ Boehm GC / WOW64でGetThreadContext（）に依存するアプリは機能しません（初心者の場合、デバッガーが古いスタックトレースを表示するのを見ました）。

EDIT2：悪いニュース。MSFT（ここ）のAlexeyとの会話から、修正によって文書化されていない機能に依存するアプリが破損することを恐れて、まったく修正されない可能性があるように見えます。

元の質問

• 次のことについて混乱している人もいるようです。私は当初、カーネルモードのコードでSuspendThreadがスレッドを一時停止したことが原因だと思っていました。そうではありませんでした。以下は、実際の根本原因とは何の関係もないことが判明した私の最初の疑惑でした。これは、によって返された古いコンテンツでしたGetThreadContext()。

MSDNから：

Suspending a thread causes the thread to stop executing user-mode (application) code.

しかし、私が見つけたのは、WOW64で実行されているWindows 7の32ビットアプリで、スレッドBでSuspendThreadを呼び出すスレッドAは、64ビットコードの実行中に一時停止できることです（ユーザーモードコードではないと思います）。EIPは、中断されたスレッドがで停止したことを示しています

ESPが変更された状態（ESPがそのスレッドのスタックと同じページを指しているときに、現在のスタックポインターよりもはるかに高いアドレスを取得しているため、これはわかっています）。上記が戻る命令にブレークポイントを設定し、スレッドを再開すると、ESPがX86SwitchTo64BitMode呼び出し（正しいスタックポインター）の前の値に戻ることがわかりました。また、同じ関数にシングルステップインすると、シングルステップのどの時点でもその高いアドレスESP値を取得できないこともわかりました。実際、シングルステップの場合、ESP値はX86SwitchTo64BitMode呼び出しの前後で変更されることはありません。

また、（DWORD）-1をチェックして、SuspendThreadが成功することを確認しました。

これらすべてから、スレッドはカーネルモードのコードで中断されていると私は信じています。

非ユーザーモードコードの実行中にOSがスレッドを一時停止する原因は何でしょうか？どうすればそれを防ぐことができますか？これは基本的に、スレッドBの実際の現在のスタックポインターを取得することを妨げています。アプリがWOW64の外部（ネイティブx86 OS上）で実行される場合、そのような問題は存在しないことに注意してください。

健全性チェックをお願いします。私が聞いている解決策は考えが間違っているように聞こえますが、唯一の解決策かもしれません。

私が実行している .vbs アプリ上の .hta 内から

CLI からはうまく機能し、小さなアプリ内からは失敗します。これは、私が 64 ビット ボックスを使用しており、c:\Windows\System32 への呼び出しが c:\Windows\SysWow64 にリダイレクトされ、iisapp.vbs スクリプトが存在しないためです。スクリプトをそこに移動すると、Microsoft.CmdLib は登録が必要であると文句を言います。これはすべて理解でき、理解できます。

他のフォーラムで推奨されている解決策は、regsvr32 IIsScHlp.wsc と cmdlib.wsc を SysWow64 にコピーすることです。

それは機能しますが、少し手間がかかるようです。このソリューションの予期しない副作用はありますか? これらのファイルを Wow64-land に再登録するより直接的な解決策はありませんか?

ありがとう。

私が作成し、ml.exeを使用してx86用にアセンブルした一部のプログラムは、Win7x64で正常に動作することを確認しました。これはWowテクノロジーのおかげだと思います。

ただし、実行されないプログラム（私が作成したものではない）がいくつかあります。次のようなエラーが発生します。 このファイルのバージョンは、実行しているWindowsのバージョンと互換性がありません。コンピュータシステム情報をチェックして、プログラムのx86（32ビット）バージョンまたはx64（64ビット）バージョンが必要かどうかを確認してから、ソフトウェア発行元に連絡してください。

これらのプログラムのEXEを変更して、Win7x64で実行できるようにする方法はありますか。透過的に実行される他のプログラムとの違いをもたらすこれらのプログラムの根本的な違いは何ですか。

WinPE 3.0 (Win7) 64 ビット環境で 32 ビット アプリを実行しようとすると、次のエラー メッセージが表示されます。

The subsystem needed to support the image type is not present.

問題の不足しているサブシステムは、Windows on Windows 64 (WOW64) です。これは、32 ビット アプリを 64 ビット OS で実行できるようにする互換性レイヤーです。

問題は、WinPE に WOW64 をインストールすることは可能でしょうか? もしそうなら、インストールするファイルのセットはどのように、どのくらいの大きさですか?

ありがとうございました。

freetype2(2.3.9) を使用して tff to D3D テクスチャ関数を作成し、フォントからグレースケール マップを生成しました。ネイティブのwin32ではうまく機能しますが、WoW64では爆発します（まあ、FT_DoneそうFT_Load_Glyphです）。一部のデバッグから、fromHeapFreeによって呼び出される問題のようです。freeFT_Free

私の知る限り freetype2 を使用する WCIII のようなゲームは問題なく動作するはずです。

ARCHIVE_LoadFileで割り当てられたブロックを返しますnew。

二次的な質問として、ピクセルサイズを使用してフォントをレンダリングしたいのですがFT_Set_Pixel_Sizes、これがフォントをサイズに合わせて拡大するのか、サイズに制限するのかはわかりません。私がやりたいのは、すべてのグリフを 24px (ここでは MS Word サイズ) でレンダリングし、それを 32px 領域の符号付き距離フィールドに変換することです。

アップデート

いろいろいじった後、テストアプリが動作するようになりました。これにより、コードがセカンダリスレッドで実行されているため、問題はスレッド化に起因すると考えられます。マルチスレッド DLL を使用して freetype を静的ライブラリにコンパイルしました。アプリはマルチスレッド ライブラリを使用します。マルチスレッドテストをセットアップできるかどうかを確認します。

また、2.4.4 に更新して、問題が既知のバグであるかどうかを確認しましたが、解決しませんでした。

更新 2

さらにいじった後、2.4.4の正しいライブラリを使用していなかったことが判明しましたFT_Done_Face. Windows のメモリ ヒープ管理で。freetype2 にバグがあり、ユーザー スレッドで爆発する可能性はありますか?

64ビットサーバーにデプロイされたWebアプリケーションがWOW64プロセスとして実行されるのか、WebアプリケーションのページがPE 32 / x86としてコンパイルされる場合は64ビットプロセスとして実行されるのかを知る必要がありますか？

つまり、64ビットサーバー上でWOW64として実行されるPE 32/x86を備えた通常のコンソールアプリケーションまたは実行可能ファイルについて多くのことを読んだことを意味します。しかし、Webアプリケーションについてはどうでしょうか（コンパイルできるのはdllであるページだけです）。私が考えることができる唯一のプロセスは、Webアプリ用のw3wp.exeです。説明してください。私は混乱しています。

前もって感謝します

ヴィニート

ここでWOW 64について読んでいました http://en.wikipedia.org/wiki/WOW64

32ビットプログラムを実行するための64ビットWindows OSのレイヤーであることを学びました。

したがって、32 ビット プログラムは、32 ビット OS でネイティブに実行される場合と比較して、64 ビット OS では比較的遅く実行されると想定できます。

64 ビット OS で 4 GB を超えるメモリ アクセスの利点が見られます。しかし、この利点は、 WOW64 のレイヤーによって追加される小さなオーバーヘッドを相殺する必要がありますか? これを相殺する64ビットの他の利点はありますか？

Delphi で 32 ビット アプリケーションを作成する アプリケーションが win32 または win64 Windows マシンで実行されているかどうかに応じて、すべてのハイブにアクセスできません。デフォルト アクセスのリンクは次のとおりです: http://msdn.microsoft.com/en-us/library/aa390789(v=VS.85).aspx

32 と 64 用の個別のバージョンではなく、単一のアプリケーションを作成したいだけです。また、WMI を使用して、32 ビット レジストリ ハイブ、64 ビット レジストリ ハイブ、および WOW6432Node から情報を取得したいと考えています。設定する FLAGS がありますが、デルファイ アプリケーションからの通常の WMI クエリ呼び出しでフラグを送信する方法がわかりません。FLAG に関する情報は次のとおりです: http://msdn.microsoft.com/en-us/library/aa393067(v=VS.85).aspx

GLibWmi & DelphiWmiCodeCreator の例:

改訂されたコード:

64 ビット Windows で正しく実行できる 32 ビット プログラムをビルドしようとしています。つまり、ユーザーのためにテキスト ファイルを開く必要がある場合、ファイルをからにリダイレクトする必要はありません。ただし、 を呼び出すだけでは、プログラムのロードにまったく失敗します。これは、GUI の一部がロードされているときに一部のシステム ライブラリが呼び出され、システム DLL の 64 ビット バージョンをプログラムにロードしようとするためです。C:\Program FilesC:\Program Files (x86)Wow64DisableWow64FsRedirectionLoadLibrary

この問題を解決するにはどうすればよいですか?

編集：

以下のスクリーンショットで問題を確認してください。

編集2：

問題を解決する別の質問があります: プロセス内の任意のスレッドまたはプロセス全体に対して WOW64 リダイレクトを無効にする方法はありますか?