Try で固まる への返答
投稿で使用できる特殊コードの説明。(別タブで開きます。)
以下の返答は逆順(新しい順)に並んでいます。
投稿者 二―ベル (社会人)
投稿日時
2019/9/3 09:50:29
DBはAccessとありますが、
プログラムはx86ビルドですか、Any CPUですか？
Any CPUだと、x64のOSでは64ビットアプリとして動作しますが、
Accessは32ビットベースでないと使えないのでは、と思いました。
プログラムはx86ビルドですか、Any CPUですか？
Any CPUだと、x64のOSでは64ビットアプリとして動作しますが、
Accessは32ビットベースでないと使えないのでは、と思いました。
投稿者 hori (社会人)
投稿日時
2019/8/29 16:10:37
魔界の仮面弁士 さま。遅くなりすみません。
オフラインでセキュリティーを外しても同じでした。
で、ちょっと時間がかかりましたが
知人に頼んで i 7 に VS2015 の載っている機械を手配してもらって
同様の環境でやってみましたところ普通に動作しました。
また、vista時代の core2 の機械で、
exe だけ走らせてみたところでも問題なく動きました。
従って、VS ではなく、僕にとってメインのＰＣに
何らかの個別の問題が発生しているものと判断いたします。
ＳＭＡＲＴ については、物理的に全く別のドライブに
データを移しても症状は変わらないので大丈夫かなと思います。
ネット情報では、それを調べるだけでも
ちょっとリスキーなように書かれていたので・・・・・・
あと、この機械で思い当たる症状としては
ヤフーに接続するときだけ前より時間がかかっているように思いますが
他のサイトは前と変わらず普通なので？？？です。
まぁ、2回目からは普通に動くので
もっとひどくなるまで辛抱して使うのがベストな選択でしょうかねぇ？・・・・
オフラインでセキュリティーを外しても同じでした。
で、ちょっと時間がかかりましたが
知人に頼んで i 7 に VS2015 の載っている機械を手配してもらって
同様の環境でやってみましたところ普通に動作しました。
また、vista時代の core2 の機械で、
exe だけ走らせてみたところでも問題なく動きました。
従って、VS ではなく、僕にとってメインのＰＣに
何らかの個別の問題が発生しているものと判断いたします。
ＳＭＡＲＴ については、物理的に全く別のドライブに
データを移しても症状は変わらないので大丈夫かなと思います。
ネット情報では、それを調べるだけでも
ちょっとリスキーなように書かれていたので・・・・・・
あと、この機械で思い当たる症状としては
ヤフーに接続するときだけ前より時間がかかっているように思いますが
他のサイトは前と変わらず普通なので？？？です。
まぁ、2回目からは普通に動くので
もっとひどくなるまで辛抱して使うのがベストな選択でしょうかねぇ？・・・・
投稿者 魔界の仮面弁士 (社会人)
投稿日時
2019/8/27 22:57:15
> 「保護されたメモリーに書き込みに行ったためエラー・・・・
> 他のメモリーが壊れている可能性がある」
これはメモリモジュールの故障を意味しているのではなく、
本来確保されている変数領域を超えた位置に、データの書き込みが
行われたことを意味します。
(VB でいうと、配列のインデックスを超えてアクセスしたようなもの)
API 処理にバグがあってメモリ操作をミスっている場合もあれば、
何らかのアプリのインストーラーが、古いバージョンの DLL を上書きしてしまい、
想定外の動作を引き起こしているといったケースもあります。
> ともかく、症状は、再起動してそのファイルにアクセスする最初の１回目だけそうなる
> 次からは問題なく作動する。
20 分経っても回復しないこともあれば、9 分後に回復することもあったのですね。
初回アクセス時に、ウイルス対策ソフトの類によるスキャンが発生しており、
それが阻害の原因になっているということは無いでしょうか?
セキュリティソフトをオフにしてみて、それでも初回実行時に遅延が発生するかを
確認してみてはいかがでしょう。
(ネットワークに繋がったままだと危険そうなので、オフラインでの実験を推奨)
それでも遅延する現象が回避できないようであれば、
ディスクから S.M.A.R.T. 警告が上がっていないか確認してみるとか…。
> 他のメモリーが壊れている可能性がある」
これはメモリモジュールの故障を意味しているのではなく、
本来確保されている変数領域を超えた位置に、データの書き込みが
行われたことを意味します。
(VB でいうと、配列のインデックスを超えてアクセスしたようなもの)
API 処理にバグがあってメモリ操作をミスっている場合もあれば、
何らかのアプリのインストーラーが、古いバージョンの DLL を上書きしてしまい、
想定外の動作を引き起こしているといったケースもあります。
> ともかく、症状は、再起動してそのファイルにアクセスする最初の１回目だけそうなる
> 次からは問題なく作動する。
20 分経っても回復しないこともあれば、9 分後に回復することもあったのですね。
初回アクセス時に、ウイルス対策ソフトの類によるスキャンが発生しており、
それが阻害の原因になっているということは無いでしょうか?
セキュリティソフトをオフにしてみて、それでも初回実行時に遅延が発生するかを
確認してみてはいかがでしょう。
(ネットワークに繋がったままだと危険そうなので、オフラインでの実験を推奨)
それでも遅延する現象が回避できないようであれば、
ディスクから S.M.A.R.T. 警告が上がっていないか確認してみるとか…。
投稿者 hori (社会人)
投稿日時
2019/8/27 22:50:00
データファイルの置き場所を変えてみましたが同じでした。
再起動していないのに同じ症状が出ました。
やっぱりメモリーがおかしいのでしょうか？
だとしたら他のアプリもまともに動かないはずだと思うのですが・・・・・
メモリーの良し悪しを調べる簡単な方法ってありますか？
再起動していないのに同じ症状が出ました。
やっぱりメモリーがおかしいのでしょうか？
だとしたら他のアプリもまともに動かないはずだと思うのですが・・・・・
メモリーの良し悪しを調べる簡単な方法ってありますか？
投稿者 hori (社会人)
投稿日時
2019/8/27 22:40:37
別のＰＣで試しました。
第7世代の i 3 でメモリー４GB 、win10 pro の
何をするのももどかしく感じるＰＣですが
件の処理に１０秒弱と、この機械としては正常と思われる状態でした。
で、元のＰＣで再度試行したのですが
「保護されたメモリーに書き込みに行ったためエラー・・・・
他のメモリーが壊れている可能性がある」
と云うような内容のメッセージが出てきました。
このＰＣは動画編集もするので64GBのメモリーを載せていますし
動画編集もサクサクできていますから、それは無いと思うのですが・・・・
ともかく、症状は、再起動してそのファイルにアクセスする最初の１回目だけそうなる
次からは問題なく作動する。
ここで、思いつきました。ファイルの場所を変えてみます。
第7世代の i 3 でメモリー４GB 、win10 pro の
何をするのももどかしく感じるＰＣですが
件の処理に１０秒弱と、この機械としては正常と思われる状態でした。
で、元のＰＣで再度試行したのですが
「保護されたメモリーに書き込みに行ったためエラー・・・・
他のメモリーが壊れている可能性がある」
と云うような内容のメッセージが出てきました。
このＰＣは動画編集もするので64GBのメモリーを載せていますし
動画編集もサクサクできていますから、それは無いと思うのですが・・・・
ともかく、症状は、再起動してそのファイルにアクセスする最初の１回目だけそうなる
次からは問題なく作動する。
ここで、思いつきました。ファイルの場所を変えてみます。
投稿者 hori (社会人)
投稿日時
2019/8/27 21:54:16
再起動して試行しました。
同じ症状が出ました。
約9分経過したところで、データテーブルの取得に成功しました。
その後、いったんアプリを終了し、再度立ち上げ
先と同じ処理をしてみるとタイムラグなく正常に作動しています。
これは、ＰＣのハード的問題なのでしょうか？
別のＰＣで試してみます・・・・・
同じ症状が出ました。
約9分経過したところで、データテーブルの取得に成功しました。
その後、いったんアプリを終了し、再度立ち上げ
先と同じ処理をしてみるとタイムラグなく正常に作動しています。
これは、ＰＣのハード的問題なのでしょうか？
別のＰＣで試してみます・・・・・
投稿者 hori (社会人)
投稿日時
2019/8/27 21:31:40
お世話になります。
魔界の仮面弁士さま。るきおさま。
データベースはアクセスで、アダプターは、OleDbDataAdapter です。
VB で Formsアプリを書いています。
最初、exe で固まったので、デバッグで調べました。
固まって20分くらい放置しましたがそのままで
exe の時はタスクマネージャーで終了しました。
デバッグの時、［一時停止］すると、Adapter のところで止まっている旨表示され
［続行］して［一時停止］を何度やっても、同じ Adapter のところで止まっています。
プログラム的に、一度、通過すれば戻って来ないはずなので
そこで止まっているのだろうと判断しました。
この返事を書くにあたり再度確かめたのですが
最初の1回目は同様の症状が出ましたが、次からは問題なく動きました。
ＶＳをいったん終了し、再度立ち上げた場合、症状は出ませんでした。
再起動した場合どうなるかこれからやってみます。
ちなみに、データベースはＰＣ内のハードディスク上に在るので
接続に時間がかかっているためなんてことはないだろうと思いますが・・・
ともかく、再起動したらどうなるかやってみます。
魔界の仮面弁士さま。るきおさま。
データベースはアクセスで、アダプターは、OleDbDataAdapter です。
VB で Formsアプリを書いています。
最初、exe で固まったので、デバッグで調べました。
固まって20分くらい放置しましたがそのままで
exe の時はタスクマネージャーで終了しました。
デバッグの時、［一時停止］すると、Adapter のところで止まっている旨表示され
［続行］して［一時停止］を何度やっても、同じ Adapter のところで止まっています。
プログラム的に、一度、通過すれば戻って来ないはずなので
そこで止まっているのだろうと判断しました。
この返事を書くにあたり再度確かめたのですが
最初の1回目は同様の症状が出ましたが、次からは問題なく動きました。
ＶＳをいったん終了し、再度立ち上げた場合、症状は出ませんでした。
再起動した場合どうなるかこれからやってみます。
ちなみに、データベースはＰＣ内のハードディスク上に在るので
接続に時間がかかっているためなんてことはないだろうと思いますが・・・
ともかく、再起動したらどうなるかやってみます。
投稿者 るきお (社会人)
投稿日時
2019/8/27 12:36:01
>Adapter.Fill のところで固まるようになりました。
どうやって確認していますか？
ステップ実行でしょうか？
実はCatchの中で固まっているということがあるのかなと思ったので念のための確認です。
魔界の仮面弁士さんの書かれていますようにTryがあると固まるという現象は聞いたことがありません。
>また、VS2019 では、1つのプロジェクトで扱えるデータベースの数が
>1つだけになったかのように聞いたのですが本当でしょうか？
>VS2015 では、基本データと累積データを別々のデータベースにできていたのですが・・・・
一般的にはノーです。データベースをいくつ扱うかはプログラム次第あり、Visual Studioのバージョンによって制限されることはありません。
ただ、Visual Studio以外でサードパーティー製のツールやライブラリを使っていたり、使用しているデータベース側に制限があるなどの可能性は否定できません。
どうやって確認していますか？
ステップ実行でしょうか？
実はCatchの中で固まっているということがあるのかなと思ったので念のための確認です。
魔界の仮面弁士さんの書かれていますようにTryがあると固まるという現象は聞いたことがありません。
>また、VS2019 では、1つのプロジェクトで扱えるデータベースの数が
>1つだけになったかのように聞いたのですが本当でしょうか？
>VS2015 では、基本データと累積データを別々のデータベースにできていたのですが・・・・
一般的にはノーです。データベースをいくつ扱うかはプログラム次第あり、Visual Studioのバージョンによって制限されることはありません。
ただ、Visual Studio以外でサードパーティー製のツールやライブラリを使っていたり、使用しているデータベース側に制限があるなどの可能性は否定できません。
投稿者 魔界の仮面弁士 (社会人)
投稿日時
2019/8/27 10:15:38
今のところ、特に思い当たる点は無いですね。済みません。
例外関連で影響がありそうな設定というと、
[デバッグ] - [ウィンドウ] - [例外設定]
[ツール] - [オプション] ⇒ デバッグ \ 全般
ぐらいですが、ここを弄ることはそうないでしょうし。
アンチウイルスが原因で動作に影響があるパターンを想像してみましたが、
それが Try 時にだけ該当するかといえば微妙なところ。
https://dixq.net/forum/viewtopic.php?t=13190
あとは、ネットワーク制限のある環境でデバッグシンボルをロードしようとして、
時間がかかっている可能性を疑ってみましたが、それならばデバッグ開始時に
遅延するだけで、やはり Try には関係無さそう…。
https://docs.microsoft.com/ja-jp/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2019
https://social.msdn.microsoft.com/Forums/ja-JP/1a94072b-0e77-46d7-96b3-fe0417a69d06/12487124961248312460123983621521205368952423012395123881235612?forum=vcgeneralja
原因が掴めないので、とりあえず情報の絞込みから始めさせてください。
> データベースからデータテーブルを取得する際
念のためにお聞きしますが、対象データベースはなんでしょうか?
> Adapter.Fill のところで固まるようになりました。
① この Adapter は何のオブジェクトですか?
TableAdapter なのか SqlDataAdapter なのか OleDbDataAdapter なのか…。
②ASP.NET アプリでしょうか? WinForms でしょうか? WPF でしょうか? それとも…。
③固まるのは、開発環境からの実行時だけですか?
それとも、EXE 単体実行時も停止しますか?
④固まった後、何十分程度で復帰するのでしょうか?
それとも、復帰せずそのままの状態なのでしょうか?
⑤固まったとき、Visual Studio もフリーズ状態になるのでしょうか?
それとも、Visual Studio からのプロジェクトの停止が可能な状態でしょうか?
⑥自作ライブラリや他社製ライブラリなど、何か追加で参照しているものがありますか?
もしあれば、それらを含まない単純な実験的プロジェクトでテストしてみた場合も、
同様に固まってしまうのでしょうか?
> 感覚としては、データ量の多い場合にそうなるのかなと思いますが、
> どういう場合にそう成り得るのか等、
自分は、データ量で問題になるという経験は無いですね。
引数が多すぎて問題になったことはありますけれども。
型付 DataSet で列数の多いテーブルが含まれていると、
『table.AddNewReportRow(………)』
などの呼び出し時に、デバッグ時の引数 256 バイト制限にひっかかって、
『スレッドがガベージ コレクションが実行できないポイントで停止したため、式を評価できません。』
と出てデバッグに失敗するという現象ならば経験があるぐらい。
（ステップ実行は出来るけど、ウォッチ式もイミディエイトも評価されないし、DataSet Viewer も使えない）
例外関連で影響がありそうな設定というと、
[デバッグ] - [ウィンドウ] - [例外設定]
[ツール] - [オプション] ⇒ デバッグ \ 全般
ぐらいですが、ここを弄ることはそうないでしょうし。
アンチウイルスが原因で動作に影響があるパターンを想像してみましたが、
それが Try 時にだけ該当するかといえば微妙なところ。
https://dixq.net/forum/viewtopic.php?t=13190
あとは、ネットワーク制限のある環境でデバッグシンボルをロードしようとして、
時間がかかっている可能性を疑ってみましたが、それならばデバッグ開始時に
遅延するだけで、やはり Try には関係無さそう…。
https://docs.microsoft.com/ja-jp/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2019
https://social.msdn.microsoft.com/Forums/ja-JP/1a94072b-0e77-46d7-96b3-fe0417a69d06/12487124961248312460123983621521205368952423012395123881235612?forum=vcgeneralja
原因が掴めないので、とりあえず情報の絞込みから始めさせてください。
> データベースからデータテーブルを取得する際
念のためにお聞きしますが、対象データベースはなんでしょうか?
> Adapter.Fill のところで固まるようになりました。
① この Adapter は何のオブジェクトですか?
TableAdapter なのか SqlDataAdapter なのか OleDbDataAdapter なのか…。
②ASP.NET アプリでしょうか? WinForms でしょうか? WPF でしょうか? それとも…。
③固まるのは、開発環境からの実行時だけですか?
それとも、EXE 単体実行時も停止しますか?
④固まった後、何十分程度で復帰するのでしょうか?
それとも、復帰せずそのままの状態なのでしょうか?
⑤固まったとき、Visual Studio もフリーズ状態になるのでしょうか?
それとも、Visual Studio からのプロジェクトの停止が可能な状態でしょうか?
⑥自作ライブラリや他社製ライブラリなど、何か追加で参照しているものがありますか?
もしあれば、それらを含まない単純な実験的プロジェクトでテストしてみた場合も、
同様に固まってしまうのでしょうか?
> 感覚としては、データ量の多い場合にそうなるのかなと思いますが、
> どういう場合にそう成り得るのか等、
自分は、データ量で問題になるという経験は無いですね。
引数が多すぎて問題になったことはありますけれども。
型付 DataSet で列数の多いテーブルが含まれていると、
『table.AddNewReportRow(………)』
などの呼び出し時に、デバッグ時の引数 256 バイト制限にひっかかって、
『スレッドがガベージ コレクションが実行できないポイントで停止したため、式を評価できません。』
と出てデバッグに失敗するという現象ならば経験があるぐらい。
（ステップ実行は出来るけど、ウォッチ式もイミディエイトも評価されないし、DataSet Viewer も使えない）
投稿者 hori (社会人)
投稿日時
2019/8/26 11:17:17
win10 pro, VS2015 でプログラムを書いていますが
データベースからデータテーブルを取得する際、ずっと
Try
Adapter.Fill(table)
Catch ex As Exception
End Try
で、正常に動いていましたが、最近になって、
Adapter.Fill のところで固まるようになりました。
Try・・・を外して
'Try
Adapter.Fill(table)
'Catch ex As Exception
'End Try
にすれば正常に動くのですが
何故そうなるのか非常に不可解です。
すべてのファイルでそうなるわけではないので
感覚としては、データ量の多い場合にそうなるのかなと思いますが、
どういう場合にそう成り得るのか等、
そのあたりの条件等ご存知の方居られましたらご教示ください。
また、VS2019 では、1つのプロジェクトで扱えるデータベースの数が
1つだけになったかのように聞いたのですが本当でしょうか？
VS2015 では、基本データと累積データを別々のデータベースにできていたのですが・・・・
データベースからデータテーブルを取得する際、ずっと
Try
Adapter.Fill(table)
Catch ex As Exception
End Try
で、正常に動いていましたが、最近になって、
Adapter.Fill のところで固まるようになりました。
Try・・・を外して
'Try
Adapter.Fill(table)
'Catch ex As Exception
'End Try
にすれば正常に動くのですが
何故そうなるのか非常に不可解です。
すべてのファイルでそうなるわけではないので
感覚としては、データ量の多い場合にそうなるのかなと思いますが、
どういう場合にそう成り得るのか等、
そのあたりの条件等ご存知の方居られましたらご教示ください。
また、VS2019 では、1つのプロジェクトで扱えるデータベースの数が
1つだけになったかのように聞いたのですが本当でしょうか？
VS2015 では、基本データと累積データを別々のデータベースにできていたのですが・・・・
x86 でコンパイルしてやってみましたが症状は同じでした。
AnyCPUで3台試しましたが他のＰＣでは起こらないようですので
このＰＣ固有の問題かと思います。
釈然とはしませんが一般的な問題ではなさそうですので
とりあえず、解決と云う事にさせていただきます。
みなさま、ありがとうございました。