読者です 読者をやめる 読者になる 読者になる

プログラムの事とか

お約束ですが「掲載内容は私個人の見解です」

YouTubeのアカウントが停止されて復活した話

その他

FF15をやるためにPS4 Proを買いました

去年の11月のことです

PS4を買ったらやりたかったのがゲーム動画のShare機能でプレイ動画がLive配信できるやつ

manuals.playstation.net

見てほしい人がいるわけでもなくとりあえず配信してました

www.youtube.com

クリア

FF15クリアしてエンディングまで配信したのがこれです

youtu.be

エンディングの一部はソフトから制限がかかって配信できないようになっています(ネタバレ対策というより曲の著作権っぽい制限?)

f:id:puni-o:20170201102129p:plain

ということでメーカー側が嫌がるようなことは何もせず(別途キャプチャソフトとか使って上記制限期間を配信したわけでもなく)ゲームはクリアしました

翌日

クリアしてもまだまだやっていない要素が残っているので、翌日も配信をしようとしたらエラーでできませんでした

その翌日にはGoogleから意味不明なメールがやってきました

f:id:puni-o:20170201102605p:plain

メールにあるようにアカウントにログインしたのでこの件はこれで終了したものだと思っていました

その後も何度やってもLive配信はできませんでした

翌年

年が明けても配信できないので少しググってみるとFF15配信者の垢BANとか出てきてました

ブラウザでYouTubeにログインしたところ私のアカウントも見事に凍結状態でした(普段YouTube使わないので・・)

この前のGoogleからのメールはこれだったんですね

このメールにあるお問い合わせページ

My account is disabled - Accounts Help

に「PS4でFF15配信してただけなのになぜ?」って日本語で書いて終了

もともと配信機能があるから配信してただけなのでそれ以来すっかり忘れてました

本日

Googleからメールがきてました

f:id:puni-o:20170201103318p:plain

アカウントが復活しました

なんだかなー

続 IISとASP.NETとApplicationPoolをいじっていたらよくわからない現象に悩まされたこと

前回のブログ

puni-o.hatenablog.com

の続き

前回の設定でちゃんと動くようになったと思っていたんですが、やっぱり駄目でした

そこそこ効果がありそうなおまじないを唱えることができたので、前回のものに追記しつつその対策までを(おまじないなので解決策になっていないですし、原因も大外れかもしれないです)

やったこと

追加 →

IISのApplication Initialization(だったっけ?)を有効にしてOS起動したら即Web APIをアクセスするようにした (これでサーバー起動してからお茶していれば使えるようになっている・・・)

現象

OSを起動してWeb APIにアクセスすると30分以上応答がかえって来ない

追加 →

イベントログをみたらアプリケーションプールの再起動が多発

アプリケーションプールのPingタイムアウトで強制終了 → 起動でWeb APIアクセスを繰り返していた

何かのタイミングでWeb APIが応答を返すと使えるようになる

Web APIと同じこと(Web API内ではサードパーティー製の64bit DLL (Cで使うやつ)をラップしたDLLをP/Invokeで使用)をするデスクトップアプリ(WPF製)を実行すると似たような現象が発生

アプリ起動 → 固まる(かなり待っても応答なし) → 強制終了 → 起動 → 動く

リソースモニタでアクセスするファイルを見ているとサードパーティ製DLLのインストールフォルダにあるファイル(DLLとかいろいろ)のアクセスで止まっている感じ(正常起動時はその後に別のデータの読み込みまで確認できる)

サードパーティ製DLLに付属しているアプリ(多分ネイティブアプリ)はすんなり動く

上記アプリを起動するとなぜか.Net製もいきなり動く

よく外れる予想

サードパーティ製DLLのOS起動後初回P/Invokeで、OS(または.Net)が何らかのセキュリティチェックを行っているのでは?

そのチェックがデッドロックしているので再起動でのみ復帰するのでは?

チェック結果はある程度保持されていて2回目以降のチェックは省略されるのでは?

という仮説を立てた

ちなみに私は仮説を立てて文章にするとよく外れる

おまじない1

プリロード専用のWeb APIを作成

上記APIではまずサードパーティ製DLL付属のアプリを起動(即殺す)

その後いつもの処理を実行

効果は微妙

おまじない2

サービスを一つ作成

サービスでサードパーティ製DLL付属のアプリを起動(即殺す)

効果はそこそこ

ということで現在はこの二つのおまじないでだましだまし使ってもらっている状態です

原因わかって解決する日は来るのだろうか・・・

IISとASP.NETとApplicationPoolをいじっていたらよくわからない現象に悩まされたこと

ASP.NET C#

原因がわかっていないので私が気付いている範囲で環境とかやったことを書きます

環境

Windows Server 2012 R2

アプリ

ASP.NET MVCでWeb API 2 (だっけ?)を作成

Web API内ではサードパーティー製の64bit DLL (Cで使うやつ)をラップしたDLLをP/Invokeで使用

サードパーティー製DLLはそこそこ大きくてそれが読むデータも大きい (データサイズは関係ないかも)

やったこと

Administratorですべてセットアップ(ランタイムのインストールとか)

アクセス権とか面倒なのでAdministratorで動くApplicationPoolを新たに作成

アプリは上記ApplicationPoolで動かすように

現象

OSを起動してWeb APIにアクセスすると30分以上応答がかえって来ない

P/InvokeしていないAPIにアクセスするとすぐに応答を返してくれる

応答が返ってこない時のディスクアクセスとかCPU使用率はそんなに上がっていない

一度応答を返すとそのあとは普通に返ってくる

応答を返し始めるタイミングは不明 (ログとか見ていると突然返す感じ)

iisreset等で再起動かけた場合はすぐに返ってくる (返ってこない場合もあったかも)

応答が返ってこない間にApplicationPoolのpingエラーで勝手にApplicationPoolが再起動させられているっぽい (?)

解決策 (?)

使用するApplicationPoolをDefaultAppPoolに戻したら現象は発生しなくなった

ユーザー(Administratorsグループ)を新規に作ってそのアカウントでApplicationPoolを動かしても問題なし (新規ユーザーは一度もログインしていない)

 

うん、全然わからない

とりあえず動いているからいいやって感じで終了