1. sk ☃#QQ
  2. Untitled project
  3. MnMn
  4. Issues

(新)アップデート処理がファイルハンドル掴んでて成功しない

Issue #552 closed
sk ☃#QQ repo owner created an issue

目安箱: 23

かなりの精神ダメージがある。

きっついなぁ、うまく行ってたと思ったんだけどなぁ。

  • 提示してもらってるログだと展開プログラムが実行されてる
  • 展開プログラム起動から実行に至る過程には MnMn の停止(名前付きイベントで制御)が必須になる
  • イベント(AutoResetEvent)が立てられてから後続行ってるからなんかこう理屈じゃなくて現実側的というか Windows 側に歩み寄らねばならんのか、(今までの人生総括的に Windows に限らず)歩み寄って和解出来たことないぞ
  • 旧処理が実施出来てるなら二思いがある
    1. 新処理失敗後に MnMn 再起動して旧処理で実行している
      • MnMn のプロセスリセットにより内蔵ブラウザがメモリ・プロセス的にリセットされてるから上書きできた
      • また新処理で出来んじゃね？ って思い
    2. 新処理失敗後にまた新処理が失敗するから旧処理を起動している
      • DLL 周りのプロセス制御が甘い
      • DLL が EXE より長生きってのも気持ち悪いが現実的に死んでるのであればこれに合わせる
      • そーゆーワケで、 10 秒くらい待てばいいんじゃね？ って思い
        • 実装としちゃ時間は App.config で外部化

まぁ何がしんどいって再現手法が確立できてないとこよね！

Software: MnMn
Version: 0.62.0.28698-00df49a828ae65219deab96c7b08fd3ef6555c16
BuildType: RELEASE
Platform: 64
OS: Microsoft Windows NT 10.0.14393.0
CLR: v4.0.30319
Lightweight: 0001-01-01 00:00:00Z

Comments (30)

  1. sk ☃#QQ reporter

    ニコ生とか見てたりとかで、内蔵ブラウザが影響すんじゃねって思うけどそれだと更新履歴表示でもこうならないとおかしいからもう💩レベルで分からん！ でも解決せねばならん！

  2. Trieste

    便利なアプリをありがとう。 というわけで詳しい話ですが。 Winを再起動したあとMnMn関連のファイルを全部削除（キャッシュやroamingは待避）した後、MnMnを再インストールして起動、規約を許諾、そのまま一切操作せず新アップデートに直行しても同じエラーが出る状態です。 常駐アプリを終了させて同じように再インストールしても同じエラーがでました。 そのため私の環境では再現率100％（たぶん）となっています。

    また、一度新アプデを失敗した後の動作ですが、MnMnやWinを再起動して新アプデをクリックしても、ファイルをダウンロードするだけで、アップデートはされない状態（MnMnが自動で閉じることもない）になり、数分待ってアップデートタブに戻ってくると、再びクリックは出来ますが、今度はDLが準備中のまま何も行われなくなります。 この場合MnMnを再起動しない限りアプデをクリックできなくなります。 旧アプデはアプデをクリック出来るかぎり、エラー無く完了します。

    大して詳しくありませんがよろしくお願いします。

  3. sk ☃#QQ reporter

    詳細ありがとうございます。

    かなり厄介なことになってますね。困りました。

    1. データ退避しているため設定は関係ない
    2. MnMn 自体も初期状態であるため全環境で発生しないと理屈上おかしい
      • MnMn 再起動しても成功しない(↑の状態であるため失敗すべき)
    3. 数分後のアップデートタブに戻った際は待機イベント完了(多分タイムアウト)のためボタン活性状態
      • アップデート実施するも進まないのは誰かがファイルをつかんでる(MnMn or Extractor?)

    開発側としては 2. が怖いんですよね。 ロジックとしては旧アップデート処理と同じなので動いてしかるべきなんですが 2. によって旧アップデート処理すら動かないことになるんですが現実動いているなら新処理がバグってるんですが差異がまだ見当つかないモヤモヤです。

    ダメもとで一度試していただきたいのですが、目安箱のインストール場所が C:\Program Files (x86)\MnMn となっていますが これをどこかドキュメントなりデスクトップなりに移して実施してもらえますか。 アップデート時に UAC 制御下で動かすことを想定していないのでもしかしたらという一握の望みを星に願いたいところです(そうなると旧処理で動くのがさらに謎なんですよね)。

    ちなみに旧アップデートは #513 で閉じる予定ですが別段すぐ閉じるわけではありません。 というのも新処理と旧処理の同時保守がしんどいだけで新処理に(大きな)機能追加しない限り残しておくことに負担はないのでまだ破棄はしません。動いているプログラムは正義です。

    少なくともこの課題を閉じても最低2-3世代は残す予定です。 むしろ共存している間に報告していただいて非常に助かってます。

  4. Trieste

    こんにちわ。 ドキュメントや別のドライブ（DとかE）で試して見ましたが同じエラーが出ました。 管理者権限でMnMnを起動しても同じエラーになります。 また、MnMnアーカイブ展開を閉じる前にd3dcompiler_47.dllをどうにかしようとするとExtractorがファイルを使用中と言われ、MnMnを起動する前にd3dcompiler_47.dllを削除等していた場合新アプデが成功します。(どちらもMnMnルートのDLL) 私の環境では変になってるのはd3dcompiler_47.dllだけみたいです。

  5. sk ☃#QQ reporter

    別の場所でのアップデート試行ありがとうございます。 ダメでしたかぁ。

    d3dcompiler_47.dll を削除した状態だと成功するのは MnMn がファイル掴んでるからだろうとは思うんですが、うーん それだと旧処理が成功する理由が分からなくなるのですよね。

    一旦 DL -> 終了 -> 展開 の流れを精査してみます。

    別件として #554, #555 を起票しました。ともに Extractor 側のログに関する処理なので本件を解決するものではありませんが関連するものですのでここに周知しておきます。

  6. sk ☃#QQ reporter

    とりあえず原因不明なので次アップデート(0.63.0)で待機時間を少し伸ばした・ログのコピペできるプログラムへ置き換え。

    次の次でその結果が分かると思います。

  7. sk ☃#QQ reporter

    追記:

    内蔵ブラウザのシャットダウンも明示的に行っておきました。

  8. sk ☃#QQ reporter
    • changed status to open

    0.63.0 でちょっと修正したのを配布。

    0.64.0 以降で何かしら動きがあると思いたい。

  9. sk ☃#QQ reporter

    どうにもウィンドウを閉じるときのログアウト処理が見た目上プログラム終了してるけど裏で頑張ってたのでプロセスが生きていたのかもしれない。

    でもそれだと旧処理で成功する理屈にはならないから微妙だけど 0.64.0 に乗せて(対応: #562) 0.65.0 以降のアップデートに期待する。

  13. sk ☃#QQ reporter

    0.65.0 で失敗報告あり。

    フォーラムで提供してもらってるログは成功時のモノっぽいので失敗時のモノの提供待ち。
    もっかしたら失敗時のモノかもしれないけどなんにせよ確認中。

  14. sk ☃#QQ reporter

    こちらで再現できない以上このまま小手先でロジック変えるのは現実的ではない。

    現行の自動アップデート処理におけるエラーはこのまま残し、再実施を容易にするのが道筋としては一番まともだと考えられる。
    なによりアップデート(展開)失敗時に再度 MnMn からアップデート実行する場合、依存モジュールと MnMn のバージョン間で不整合発生により MnMn を起動できない危険が大きい。

    よって例外発生時は再実施を容易に行えるよう組み替えようと思うが一応別案も考える。

    1. 展開処理を容易に再実施できるようにする
    2. AppDomain から分離して(依存モジュールの切断) MnMn 内で展開する(多分これは調査だけで工数がぱない)

    本対応は 0.67.0 で公開され、 0.68.0 で運用される見通し。

  21. sk ☃#QQ reporter

    #651 見てたらすっげー内容が頭の中に降りてきた。

    展開処理側の WPF が d3dcompiler_47.dll 掴んでんじゃないのか。
    この場合 MnMn が <MnMn>\lib\firefox を Path を追加した状態で起動するから MnMn 側のライブラリを WPF が使用する、みたいな。

  22. sk ☃#QQ reporter

    単体起動

    単体起動.png

    連携起動

    連携起動.png

    環境変数殺せばいけるんだろうか。
    コストないし試してみよう。

  23. sk ☃#QQ reporter

    0.71.0 -> 0.72.0 でダメだった模様。

    もうなにがなんだか。

    プロセス掴んでるやつは誰なのか、なのか。これコードで出すの負担やでぇ。

  24. sk ☃#QQ reporter

    報告情報をまとめると Extractor が d3d-.dll を掴んでいる。

    ↑の Path 切ったもののなんかダメだった。
    恐らく子プロセス的な扱いで app.config:lib 継承したかそれ以外の要因で lib/firefox 読めるんだろうね。

    WPF が d3d-.dll を使用するけどこれがシステムじゃなくてローカルの方使うのが問題であって、WPF 以外の実装なら問題ないハズ。

    Forms かぁ。。。今さらしんどいなぁ。

    旧版は完全に安定稼働してるからそこに手は入れられない、というかやっばい不具合でもない限り手を入れるのは自重すべき。

  26. sk ☃#QQ reporter

    ちょっと試したいことが出来た。

    これ、カレントディレクトリじゃね？

  27. sk ☃#QQ reporter

    β版をユーザー確認待ち、これがOKだったら万歳。

    NGだったら Forms 版でちまちま作る。

  29. sk ☃#QQ reporter

    次回バージョン(0.74.0->0.75.0)のアップデートまで閉じずにおいておく。

    事の顛末としては .NET Framework 4.7 で d3dcompiler_47.dll が必要になる。
    本来なら .NET Framework から読まれるところが <MnMn>\lib\Firefox から読み込まれていた。

    GAC から読めよって言うグチは置いといて、 GeckoFx の初期化処理に Gecko のライブラリパス(<MnMn>\lib\Firefox)を渡すがその内部で SetDllDirectory を行っていた。

    そのため DLL 読み込み設定が MnMn の知らないところで変更されておりフレームワークとしての WPF が何かしらの依存関係で自動読み込み対象とし、 ファイルを掴んだままになっていた。

    なのでプロセス実行(子プロセス生成時)の場合に SetDllDirectory に空文字放り込んで実行後に戻しを掛けるようにした。
    (戻さないと次は GeckoFx が死にそうな気がしたから)

  31. Log in to comment
Assignee
Type
bug
Priority
blocker
Status
closed
Component
application/extractor
Votes
0
Watchers
1
Jira Software: the preferred issue tracker for Bitbucket. Join the team!