うまく動作しないときの対応
こんにちわ。 SB C&S の後藤です。
さて、トラブルシューティングのディープ回です。
私が ThinApp のエンジニアになるにあたり、老師(前任の専任エンジニア)がトラブルシューティングの心得を伝授してくれました。
考えるな、感じ...（以下自主規制）
なんにせよ、感じ取るにもテクニックが必要になります。今回はそのテクニックの一端をご紹介します。
アプリがうまく動作しなかった場合は、原因を探って対策を講じる必要があります。
今回はそのようなときに確認することや試してみることをいくつか紹介します。前回の動作確認についての記事もあわせて参考にしてください。
残念ながら手を尽くしても改善しない場合もあります。ある程度期間を決めて取り組むようにすることをお勧めします。
アプリが出力するエラーメッセージを確認する
アプリ自身が出力するエラーメッセージがあれば、まずその情報を収集します。
UI上にダイアログなどで表示されるエラーメッセージが一番分かりやすい例です。
アプリが独自のログファイルを出力する場合は、そのファイルにエラーが書き込まれていないか調査します。書き込み先によってはサンドボックスに保存されるので注意してください。
Windowsのイベントログを確認する
イベントビューアーを開いて関連するログがあるか確認します。
「Windowsログ」→「Application」と選択して表示します。
仮想アプリ以外のログも出力されるため、イベントビューアーと仮想アプリを両方開いておいて、エラーなどが出た瞬間に追加されるログを確認すると良いでしょう。
必ずしも役に立つ情報が得られるとは限りませんが、不具合が出た際には必ず確認しておきたい場所です。
Log Monitorでログを取得する
Log MonitorはThinAppが提供しているログ収集ツールです。
Log Monitorの起動
Log MonitorはThinAppのインストールフォルダーにあるlog_monitor.exeを実行すると起動できます。
ThinAppをインストールしていない環境でも、Setup Capture.exe、log_monitor.exe、logging.dll、logging64.dllの4つをコピーすると使用できます。これらのファイルはThinAppインストールフォルダーに保存されています。
ThinAppがインストールされている環境では、Windowsのスタートメニューにも登録されています。Omnissa内のLog Monitorを選択してください。
ログの取り方
基本的な使い方は、先にLog Monitorを起動して、その後に対象となる仮想アプリを起動する方法です。この状態でLog Monitorは自動的に仮想アプリのログを記録します。
Log Monitorはエラーの有無に関わらず、Windows APIの呼び出しやDLLのロード、関数の実行など、さまざまな仮想アプリのアクティビティをロギングします。このため、Log Monitorを起動した状態でアプリを長く操作していると膨大なログが出力されてしまいます。
これを極力防ぐために、エラーが発生する直前までログの取得を停止しておく方法があります。
ロギングを一時停止するには「Suspend」のチェックボックスをオンにしておきます。この状態で対象アプリを開いて操作し、エラーが発生する直前でSuspendをオフにします。エラー発生後は速やかに仮想アプリを終了させます。
起動時にエラーとなって強制終了してしまうようなアプリの場合はSuspendを使用する必要はありません。
ログ取得の実例
実際にログを取る流れを紹介します。例として、問題なく動作している仮想化Notepad++を使用して、「新規作成」のタイミングをターゲットにしてログを取得します。
まずLog Monitorを起動します。
起動したら「Suspend」チェックボックスを有効にします。
次にNotepad++を起動します。
起動時にログが生成されますが、これはシステム構成などの情報が出力されるためです。
今回は「新規作成」の操作をターゲットとするので、アプリの起動が完了した段階で「Suspend」チェックボックスをオフにします。
Notepad++上で「新規作成」ボタンをクリックします。新規ファイルが作成されて表示されたら、Notepad++を終了します。
ログは.traceファイルで記録されます。内容を読むためにはテキストファイルに変換する必要があります。
ファイルを一覧から選択して「Generate text trace report」ボタンをクリックします。今回はnotepad++.exeから始まるログをテキストファイルに変換しています。
ログファイルは画像のように複数作成されることが多いです。どれを見るべきか分からないときは、すべてテキストファイルに変換してください。
.traceファイルは、Log Monitorを使っていつでもテキストファイルに変換できます。
ログファイルの読み方
まず、ログのテキストファイルをWindowsのメモ帳で開くことはお勧めしません。ファイルの容量が大きくなることが多いため、開くのに時間がかかったり、開けなかったりする場合があります。
代わりにVS CodeやNotepad++など別のエディターを使用してください。PowerShellを使って分割して開く方法もあります。
ログファイルを開いたら、「Potential Errors Detected」（検出された潜在的なエラー）という行をまず探します。この行の下に、ログ中でエラーとなっている部分が集約されています。
特定のDLLでエラーが出ていないかなど、手がかりをじっくり探してください。
潜在的なエラーのすべてが不具合の原因という訳ではありません。不具合のない仮想アプリでもエラーが記録される場合があります。
潜在的なエラーの少し上、「
以下にAPI呼び出しログのフォーマットを図示します（改行がありますが2行で1つのログです）。
実際には膨大なログのなかからエラーの該当箇所を探すことに時間を費やすことになります。フォーマットについては参考程度に見ておいてください。
ログファイルの内容から不具合の原因を探るのはかなり難しい作業です。内容がわからなくても、一連の作業を知っておくとサポートを受ける際などに役立つかもしれません。
VOSで動作するアプリか確認する
この項目は、ダーティテストで起動すらしないアプリに対して行う検証です。
対象アプリがThinAppのVOS上でそもそも動作するのか、仮想cmd.exeからローカルインストールしたアプリを呼び出して確認します。
この手順では専用の仮想アプリを作成する必要があります。一度作成しておけば使い回せるため、あらかじめ用意しておくと便利です。
仮想cmd.exeの作成
Setup Captureでアプリをまったくインストールせずに仮想アプリを作成します。
クリーンなWindowsでThinAppをインストールし、Setup Captureを実行します。
プレスキャンが終わったら、すぐにポストスキャンを実行します。
cmd.exeがエントリーポイント候補として表示されるので、有効にします。
その他の設定は特に変更しません。キャプチャ時のWindowsバージョンなどをインベントリ名に入力しておくと分かりやすいです。
この仮想cmd.exeから通常インストールした対象アプリを呼び出します。
上の画像では仮想cmd.exeからインストール済みのnotepad++.exeを実行しています。
ここで問題なく起動すれば、キャプチャのやり直しやPackage.iniの調整によって動作する仮想アプリになる可能性が出てきます。
逆にアプリが起動しない場合は、仮想化はほぼ諦める状況になります。
プロジェクトフォルダーの編集
パッケージ内のファイルやレジストリデータに原因がないか、プロジェクトフォルダーを直接編集して確認します。
動作の確認はダーティテストの環境（キャプチャ環境）で行い、原因が絞れたらクリーンテストなどを実行していきます。
レジストリ内容の削除
レジストリデータが記述されているHKEY_CURRENT_USER.txt、HKEY_LOCAL_MACHINE.txt、HKEY_USERS.txtの内容を編集します。
これら3つのテキストファイルを開き、内容をすべて削除して上書き保存します。
レジストリ情報が空の状態で再ビルドし、動作を確認します。動作確認前にサンドボックスも削除することを推奨します。
これで動作が改善した場合は、レジストリの内容に問題があると判断できます。次にファイルごとに内容を元に戻し、どのファイルの内容が原因となっているかを特定します。
ファイルが特定できたら、ファイル内の絞り込みを行います。
レジストリデータの一部だけを戻してビルドし、どの部分が問題となっているかが判明するまで、ファイル編集 → 再ビルド → 動作確認を繰り返します。
問題箇所だけを削除した状態で動作する仮想アプリが作成できたら、他の環境でテストして動作を確認していきます。
ファイルの削除
レジストリデータではなく、プロジェクトフォルダー内のファイルを削除して動作を確認することもできます。
テストの流れはレジストリとほぼ同じで、ファイルを削除して再ビルドし、状況が改善した場合は少しずつファイルを戻して再ビルドしながら原因を特定します。
アプリ本体のEXEファイルなど、削除し過ぎないように注意してください。
Package.iniの調整
Package.iniを調整して改善を試みます。
テスト用エントリーポイントの有効化
直接動作を解決する設定ではありませんが、確認手段を増やすためによく使用するため、ここでも紹介しておきます。
Package.ini末尾にcmd.exeとregedit.exeのセクションがあるので、それぞれDisabledの行を;でコメントアウトしてください。
[cmd.exe]
Source=%SystemSystem%\cmd.exe
Shortcut=Notepad++.exe
;Disabled=1
[regedit.exe]
Source=%SystemRoot%\regedit.exe
Shortcut=Notepad++.exe
;Disabled=1
cmd.exeではコマンドを使用して仮想環境内のファイルシステムにアクセスできます。
注意点として、仮想アプリがcmd.exeを指定して呼び出し処理を行うような場合、エントリーポイントのcmd.exeが実行されてしまい、動作がそこで止まってしまう可能性があります。cmd.exe is already ThinApp'ed, cannot execute in virtual environment ***といったログが出ている場合はその状態に該当します。
cmd.exeに限らず、エントリーポイントはユーザーが直接実行するものを適切に指定するようにしてください。
圧縮設定の解除
パッケージの圧縮設定を指定している場合は、これを解除します。これだけで問題が解消される場合もあります。
圧縮はビルド時間が伸びるなどの弊害もあるため、最初から設定するのは避けてください。
圧縮設定が入っているかどうかはCompressionTypeを確認します。圧縮をやめるにはNoneを指定します。
[Compression]
CompressionType=None
OptimizeForパラメータはそのままで問題ありません。
子プロセスの仮想環境外での実行
仮想アプリがローカルインストールされたアプリやWindowsの機能を呼び出す際に不具合が起きている場合、そのプロセスを仮想環境外で実行するよう指定することで改善する場合があります。
よくある例として、仮想アプリからインストール済みのOffice製品を起動するケースがあります。Office向けの設定はPackage.iniにあらかじめ用意されているため、コメントアウトを解除して再ビルドするだけで適用できます。
以下の例は、32ビット仮想アプリからの印刷で不具合が出る場合に行う指定です。
[BuildOptions]
ChildProcessEnvironmentExceptions=splwow64.exe
マニフェストのコピー
アプリ内部でDLLのロードに失敗している可能性がある場合にはCopyManifestDataを試します。これはエントリーポイントのEXEファイルにアプリのマニフェストをコピーする設定です。
[BuildOptions]
CopyManifestData=1
その他のパラメータ
Package.iniのドキュメントを参考に、解決しそうなパラメータを試す場合もあります。
各種ログなどで情報を取得しつつ、エラーに対して効果がありそうなパラメータを探してはPackage.iniを編集し、再ビルドすることを繰り返してください。
新しいThinAppでのビルド
使用しているThinAppのバージョンが古い場合、最新のThinAppを使用することで解決するケースがあります。
エントリーポイントのファイルからThinAppバージョンを知る方法
コマンドプロンプトからビルドに使われたThinAppのバージョンを調べることができます。仮想化したEXEに-ThinstallVersionオプションを付けて実行します。
vapp.exe -ThinstallVersion
Omnissa ThinApp Runtime Version 2503.0.0-187
Built Feb 19 2025
ここに表示される"Built"の日付はThinAppのビルド日付です。
ThinAppのアップデート
ThinAppのバージョンが最新でない場合はアップデートを試してみます。
まずPCに最新のThinAppをインストールします。手順は省略しますが、インストーラーの指示に従って進めてください。
この状態でプロジェクトフォルダーのbuild.batを実行するだけで、仮想アプリに対するThinAppのアップデートも完了します。
例外として、VMware ThinAppからOmnissa ThinAppへアップデートする場合はインストールパスが変更されるため、少し修正が必要です。
build.batをテキストエディターで開き、VMwareの箇所をOmnissaに置き換えてください。
Windowsセキュリティ設定の変更
イベントビューアーでntdll.dllによるエラーが発生している場合、Windowsの制御フローガード（CFG）に引っかかっている可能性があります。
CFGの設定はWindows セキュリティを開き、「アプリとブラウザー コントロール」内の「Exploit protection の設定」を選択すると表示されます。
「システム設定」と「プログラム設定」の2つのタブが存在しています。プログラム設定ではEXEを選択してシステム設定を上書きします。
CFGが原因であると疑われる場合は、まずシステム設定でCFGをオフにしてみてください。Windowsを再起動して変更を適用してから、仮想アプリの動作を検証します。
エラーが解消された場合はシステム設定を「既定値を使用する」に戻し、プログラム設定によって対応できないかを検証します。
「プログラム設定」タブを選び、「プログラムを追加してカスタマイズ」の横にある「+」ボタンをクリックして、「プログラムのファイル名で追加」を選択します。
仮想アプリのファイル名を入力して「追加」します。
「制御フローガード (CFG)」を「システム設定の上書き」にし、その下のスイッチをオフにします。「適用」をクリックすれば完了です。
すでにアプリが起動している場合は一旦終了してから動作を確認してください。
これで動作すれば、本番環境でもこの設定を導入するか検討します。
システム全体設定で動作が改善したのに個別設定では改善しない場合、複数のEXEファイルに対してCFGをオフにする必要があります。関連するファイルを追加設定してみてください。
CFGによるエラーはWindowsの大型アップデートによって起こることが多いです。そのWindowsバージョンに対応したThinAppでビルドし直すことで、ほぼ解決します。
OSをアップデートする際にはThinAppのリリースノートも確認するようにしてください。
リリースノートは以下のアドレスから「リリースノート」を選んでください。
https://docs.omnissa.com/ja-JP/category/ThinApp
おわりに
アプリが動作しない場合の対応は、とにかく情報を集めて仮説を立て、再ビルドを繰り返していく作業です。
ここで紹介した内容は、最近試したことや実際に解決につながった事例を中心にまとめています。他にも思いついたことがあれば、とにかく試してみてください。
執筆協力
Nagisaworks 伊藤さま
ThinApp技術指南
著者紹介
SB C&S株式会社
ICT事業本部 技術本部
ソリューション技術統括部 技術推進室
後藤 正幸
