(新)アップデート処理がファイルハンドル掴んでて成功しない
目安箱: 23
かなりの精神ダメージがある。
きっついなぁ、うまく行ってたと思ったんだけどなぁ。
- 提示してもらってるログだと展開プログラムが実行されてる
- 展開プログラム起動から実行に至る過程には MnMn の停止(名前付きイベントで制御)が必須になる
- イベント(AutoResetEvent)が立てられてから後続行ってるからなんかこう理屈じゃなくて現実側的というか Windows 側に歩み寄らねばならんのか、(今までの人生総括的に Windows に限らず)歩み寄って和解出来たことないぞ
- 旧処理が実施出来てるなら二思いがある
- 新処理失敗後に MnMn 再起動して旧処理で実行している
- MnMn のプロセスリセットにより内蔵ブラウザがメモリ・プロセス的にリセットされてるから上書きできた
- また新処理で出来んじゃね? って思い
- 新処理失敗後にまた新処理が失敗するから旧処理を起動している
- DLL 周りのプロセス制御が甘い
- DLL が EXE より長生きってのも気持ち悪いが現実的に死んでるのであればこれに合わせる
- そーゆーワケで、 10 秒くらい待てばいいんじゃね? って思い
- 実装としちゃ時間は App.config で外部化
- 新処理失敗後に MnMn 再起動して旧処理で実行している
まぁ何がしんどいって再現手法が確立できてないとこよね!
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)
-
reporter -
便利なアプリをありがとう。 というわけで詳しい話ですが。 Winを再起動したあとMnMn関連のファイルを全部削除(キャッシュやroamingは待避)した後、MnMnを再インストールして起動、規約を許諾、そのまま一切操作せず新アップデートに直行しても同じエラーが出る状態です。 常駐アプリを終了させて同じように再インストールしても同じエラーがでました。 そのため私の環境では再現率100%(たぶん)となっています。
また、一度新アプデを失敗した後の動作ですが、MnMnやWinを再起動して新アプデをクリックしても、ファイルをダウンロードするだけで、アップデートはされない状態(MnMnが自動で閉じることもない)になり、数分待ってアップデートタブに戻ってくると、再びクリックは出来ますが、今度はDLが準備中のまま何も行われなくなります。 この場合MnMnを再起動しない限りアプデをクリックできなくなります。 旧アプデはアプデをクリック出来るかぎり、エラー無く完了します。
大して詳しくありませんがよろしくお願いします。
-
reporter 詳細ありがとうございます。
かなり厄介なことになってますね。困りました。
- データ退避しているため設定は関係ない
- MnMn 自体も初期状態であるため全環境で発生しないと理屈上おかしい
- MnMn 再起動しても成功しない(↑の状態であるため失敗すべき)
- 数分後のアップデートタブに戻った際は待機イベント完了(多分タイムアウト)のためボタン活性状態
- アップデート実施するも進まないのは誰かがファイルをつかんでる(MnMn or Extractor?)
開発側としては 2. が怖いんですよね。 ロジックとしては旧アップデート処理と同じなので動いてしかるべきなんですが 2. によって旧アップデート処理すら動かないことになるんですが現実動いているなら新処理がバグってるんですが差異がまだ見当つかないモヤモヤです。
ダメもとで一度試していただきたいのですが、目安箱のインストール場所が
C:\Program Files (x86)\MnMn
となっていますが これをどこかドキュメントなりデスクトップなりに移して実施してもらえますか。 アップデート時に UAC 制御下で動かすことを想定していないのでもしかしたらという一握の望みを星に願いたいところです(そうなると旧処理で動くのがさらに謎なんですよね)。
ちなみに旧アップデートは #513 で閉じる予定ですが別段すぐ閉じるわけではありません。 というのも新処理と旧処理の同時保守がしんどいだけで新処理に(大きな)機能追加しない限り残しておくことに負担はないのでまだ破棄はしません。動いているプログラムは正義です。
少なくともこの課題を閉じても最低2-3世代は残す予定です。 むしろ共存している間に報告していただいて非常に助かってます。
-
こんにちわ。 ドキュメントや別のドライブ(DとかE)で試して見ましたが同じエラーが出ました。 管理者権限でMnMnを起動しても同じエラーになります。 また、MnMnアーカイブ展開を閉じる前にd3dcompiler_47.dllをどうにかしようとするとExtractorがファイルを使用中と言われ、MnMnを起動する前にd3dcompiler_47.dllを削除等していた場合新アプデが成功します。(どちらもMnMnルートのDLL) 私の環境では変になってるのはd3dcompiler_47.dllだけみたいです。
-
reporter -
reporter とりあえず原因不明なので次アップデート(0.63.0)で待機時間を少し伸ばした・ログのコピペできるプログラムへ置き換え。
次の次でその結果が分かると思います。
-
reporter 追記:
内蔵ブラウザのシャットダウンも明示的に行っておきました。
-
reporter - changed status to open
0.63.0 でちょっと修正したのを配布。
0.64.0 以降で何かしら動きがあると思いたい。
-
reporter どうにもウィンドウを閉じるときのログアウト処理が見た目上プログラム終了してるけど裏で頑張ってたのでプロセスが生きていたのかもしれない。
でもそれだと旧処理で成功する理屈にはならないから微妙だけど 0.64.0 に乗せて(対応:
#562) 0.65.0 以降のアップデートに期待する。 -
reporter 0.63.0 モジュールで処理失敗報告あり: https://groups.google.com/d/topic/mnmn-forum/PQdgC599BFI/discussion
0.64.0 処理は手を入れてるしまずは再現手順確立かなぁ。
-
reporter 75ff9ade7492a823d3c26fc891c6dcdb7f949c3b
旧アップデート処理と同じだったプロセス監視処理にメスを入れた。 0.65.0に乗せたので0.66.0アップデート時に実行される予定。
-
reporter 0.64.0 モジュールはダメだったとさ! 残念!
-
reporter 0.65.0 で失敗報告あり。
フォーラムで提供してもらってるログは成功時のモノっぽいので失敗時のモノの提供待ち。
もっかしたら失敗時のモノかもしれないけどなんにせよ確認中。 -
reporter - changed component to application/extractor
こちらで再現できない以上このまま小手先でロジック変えるのは現実的ではない。
現行の自動アップデート処理におけるエラーはこのまま残し、再実施を容易にするのが道筋としては一番まともだと考えられる。
なによりアップデート(展開)失敗時に再度 MnMn からアップデート実行する場合、依存モジュールと MnMn のバージョン間で不整合発生により MnMn を起動できない危険が大きい。よって例外発生時は再実施を容易に行えるよう組み替えようと思うが一応別案も考える。
- 展開処理を容易に再実施できるようにする
- AppDomain から分離して(依存モジュールの切断) MnMn 内で展開する(多分これは調査だけで工数がぱない)
本対応は 0.67.0 で公開され、 0.68.0 で運用される見通し。
-
reporter - changed version to 0.67.0
-
reporter - removed version
Removing version: 0.67.0 (automated comment)
-
reporter おおお?
再実行できる作りになってるぞこれ。
-
reporter とりあえず強制でログ出したりなんやしたりする。
-
reporter 15ec0e79f5ff1beb235e9a9ff4ae64ae1e7bbf63
待ち時間追加したりリトライしたり。
-
reporter うぇ~、まだダメっぽい。
-
reporter #651見てたらすっげー内容が頭の中に降りてきた。展開処理側の WPF が
d3dcompiler_47.dll
掴んでんじゃないのか。
この場合 MnMn が<MnMn>\lib\firefox
をPath
を追加した状態で起動するから MnMn 側のライブラリを WPF が使用する、みたいな。 -
reporter 単体起動
連携起動
環境変数殺せばいけるんだろうか。
コストないし試してみよう。 -
reporter 0.71.0 -> 0.72.0 でダメだった模様。
もうなにがなんだか。
プロセス掴んでるやつは誰なのか、なのか。これコードで出すの負担やでぇ。
-
reporter 報告情報をまとめると
Extractor
が d3d-.dll を掴んでいる。↑の Path 切ったもののなんかダメだった。
恐らく子プロセス的な扱いで app.config:lib 継承したかそれ以外の要因で lib/firefox 読めるんだろうね。WPF が d3d-.dll を使用するけどこれがシステムじゃなくてローカルの方使うのが問題であって、WPF 以外の実装なら問題ないハズ。
Forms かぁ。。。今さらしんどいなぁ。
旧版は完全に安定稼働してるからそこに手は入れられない、というかやっばい不具合でもない限り手を入れるのは自重すべき。
-
reporter - marked as blocker
割り込みがないことを信じてこれだけでも早めリリースするべ。
-
reporter ちょっと試したいことが出来た。
これ、カレントディレクトリじゃね?
-
reporter β版をユーザー確認待ち、これがOKだったら万歳。
NGだったら Forms 版でちまちま作る。
-
reporter - changed status to resolved
resolved
#552→ <<cset 32b168519603>>
-
reporter - changed status to on hold
次回バージョン(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 が死にそうな気がしたから) -
reporter - changed status to closed
Fooooooo!
- Log in to comment
ニコ生とか見てたりとかで、内蔵ブラウザが影響すんじゃねって思うけどそれだと更新履歴表示でもこうならないとおかしいからもう💩レベルで分からん! でも解決せねばならん!