回答編集履歴
9
事象を箇条書きに変更
test
CHANGED
|
@@ -24,11 +24,21 @@
|
|
|
24
24
|
|
|
25
25
|
|
|
26
26
|
|
|
27
|
+
そのときの記憶では、
|
|
28
|
+
|
|
27
|
-
その
|
|
29
|
+
- そのリストを元に作成したオブジェクトをViewModelのプロパティにセットする処理をソケット受信毎に行っていたため、UIスレッドのメッセージキューが溜まっていた
|
|
30
|
+
|
|
31
|
+
- スレッドの処理が途中で止まることでスレッド数がデフォルト最大の1000いくつかになっていた
|
|
28
32
|
|
|
29
33
|
|
|
30
34
|
|
|
35
|
+
などとかなり阿鼻叫喚な状態でした。
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
31
|
-
結局は根本原因を掴むことができなかったため、そもそも論としてメモリにリソースを溜めないよう作り直しました。
|
|
39
|
+
結局は根本原因を掴むことができなかったため、そもそも論としてメモリにリソースを溜めないよう作り直しました。
|
|
40
|
+
|
|
41
|
+
それから1年以上経過し運用を続けていますが、同様の事象には陥らなくなりました。
|
|
32
42
|
|
|
33
43
|
|
|
34
44
|
|
|
@@ -48,4 +58,8 @@
|
|
|
48
58
|
|
|
49
59
|
今までの話を整理して、もし.NET側のエラーだった場合は**アプリでキャッチしてログ出力はできない**ということになります。
|
|
50
60
|
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
ただし、根本原因はアプリケーションやハード周りの問題がほとんどだと思うので、
|
|
64
|
+
|
|
51
|
-
|
|
65
|
+
今までの事象を整理して怪しい所を見直しつつ逐次対応する事が現状取れる一番の対策な気がします。
|
8
文法の修正
test
CHANGED
|
File without changes
|
7
文法の修正
test
CHANGED
|
@@ -20,17 +20,15 @@
|
|
|
20
20
|
|
|
21
21
|
そのときはリストに要素が無限に溜まり続けたことによって稀に発生しうる事象でした。
|
|
22
22
|
|
|
23
|
-
(`OutOfMemoryException`は起きなかった
|
|
23
|
+
(`OutOfMemoryException`は起きなかった)
|
|
24
24
|
|
|
25
25
|
|
|
26
26
|
|
|
27
|
-
そのときの記憶では、そのリストを元に作成したデータをViewModelのプロパティにセットしていたのでUIスレッドのメッセージキューが溜まっていたりとか、スレッドの処理が途中で止ま
|
|
27
|
+
そのときの記憶では、そのリストを元に作成したデータをViewModelのプロパティにセットしていたのでUIスレッドのメッセージキューが溜まっていたりとか、スレッドの処理が途中で止まることでスレッド数がデフォルト最大の1000いくつかになってしまったりと阿鼻叫喚な状態でした。
|
|
28
28
|
|
|
29
29
|
|
|
30
30
|
|
|
31
|
-
結局は根本原因を掴むことができなかったため、そもそも論としてメモリにリソースを溜めないよう作り直しました。
|
|
31
|
+
結局は根本原因を掴むことができなかったため、そもそも論としてメモリにリソースを溜めないよう作り直しました。それから1年以上経過し運用を続けていますが、同様の事象には陥らなくなりました。
|
|
32
|
-
|
|
33
|
-
それから1年以上経過し運用を続けていますが、同様の事象には陥らなくなりました。
|
|
34
32
|
|
|
35
33
|
|
|
36
34
|
|
|
@@ -50,4 +48,4 @@
|
|
|
50
48
|
|
|
51
49
|
今までの話を整理して、もし.NET側のエラーだった場合は**アプリでキャッチしてログ出力はできない**ということになります。
|
|
52
50
|
|
|
53
|
-
ただし根本原因はアプリケーションやハード周りの問題がほとんどだと思うので、今までの事象を整理して怪しい所を見直しつつ対応する事が現状取れる一番の対策な気がします。
|
|
51
|
+
ただし根本原因はアプリケーションやハード周りの問題がほとんどだと思うので、今までの事象を整理して怪しい所を見直しつつ、逐次対応する事が現状取れる一番の対策な気がします。
|
6
文法の修正
test
CHANGED
|
@@ -44,12 +44,10 @@
|
|
|
44
44
|
|
|
45
45
|
|
|
46
46
|
|
|
47
|
-
なので、
|
|
48
|
-
|
|
49
47
|
> どうにかキャッチしてログを出力したい
|
|
50
48
|
|
|
51
49
|
|
|
52
50
|
|
|
53
|
-
|
|
51
|
+
今までの話を整理して、もし.NET側のエラーだった場合は**アプリでキャッチしてログ出力はできない**ということになります。
|
|
54
52
|
|
|
55
|
-
ただし
|
|
53
|
+
ただし根本原因はアプリケーションやハード周りの問題がほとんどだと思うので、今までの事象を整理して怪しい所を見直しつつ対応する事が現状取れる一番の対策な気がします。
|
5
追記
test
CHANGED
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
|
|
29
29
|
|
|
30
30
|
|
|
31
|
-
結局
|
|
31
|
+
結局は根本原因を掴むことができなかったため、そもそも論としてメモリにリソースを溜めないよう作り直しました。
|
|
32
32
|
|
|
33
33
|
それから1年以上経過し運用を続けていますが、同様の事象には陥らなくなりました。
|
|
34
34
|
|
4
追記
test
CHANGED
|
@@ -20,7 +20,17 @@
|
|
|
20
20
|
|
|
21
21
|
そのときはリストに要素が無限に溜まり続けたことによって稀に発生しうる事象でした。
|
|
22
22
|
|
|
23
|
+
(`OutOfMemoryException`は起きなかった。)
|
|
24
|
+
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
そのときの記憶では、そのリストを元に作成したデータをViewModelのプロパティにセットしていたのでUIスレッドのメッセージキューが溜まっていたりとか、スレッドの処理が途中で止まったりしてスレッド数がデフォルト最大の1000いくつかになってしまったりと阿鼻叫喚な状態でした。
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
23
|
-
根本原因は掴めなかったため、そもそもメモリにリソースを溜めないよう作り直しました。
|
|
31
|
+
結局、根本原因は掴めなかったため、そもそもメモリにリソースを溜めないよう作り直しました。
|
|
32
|
+
|
|
33
|
+
それから1年以上経過し運用を続けていますが、同様の事象には陥らなくなりました。
|
|
24
34
|
|
|
25
35
|
|
|
26
36
|
|
3
追記
test
CHANGED
|
File without changes
|
2
追記
test
CHANGED
|
@@ -4,7 +4,13 @@
|
|
|
4
4
|
|
|
5
5
|
|
|
6
6
|
|
|
7
|
+
> UnhandledExceptionでキャッチできずアプリケーションが停止する例外には、
|
|
8
|
+
|
|
9
|
+
どのようなものがありますでしょうか？
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
|
|
7
|
-
|
|
13
|
+
おそらく、**.NET Framework の内部処理で発生する例外**だと思います。
|
|
8
14
|
|
|
9
15
|
詳しい例外の話については、[.NET Framework の内部処理で発生する例外について](https://blogs.msdn.microsoft.com/jpvsblog/2014/09/16/net-framework/)が参考になるかもしれません。
|
|
10
16
|
|
|
@@ -18,10 +24,22 @@
|
|
|
18
24
|
|
|
19
25
|
|
|
20
26
|
|
|
21
|
-
> デバッグ実行できる環境ではないため発生している箇所もわからず対策
|
|
27
|
+
> デバッグ実行できる環境ではないため発生している箇所もわからず対策が取れません
|
|
22
28
|
|
|
23
29
|
|
|
24
30
|
|
|
25
31
|
補足されなかった例外は基本的にイベントログで確認できます。
|
|
26
32
|
|
|
27
33
|
可能なら、そこでエラーの内容を確認できると原因を調査できるかもしれません。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
なので、
|
|
38
|
+
|
|
39
|
+
> どうにかキャッチしてログを出力したい
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
アプリでキャッチしてログ出力は、もし.NET側のエラーだった場合は「できない」ということになります。
|
|
44
|
+
|
|
45
|
+
ただし、根本原因はアプリケーションやハード周りの問題がほとんどだと思うので、今までの事象を整理して怪しい所を見直しつつ対応というのが現状な気もします。
|
1
文章の修正
test
CHANGED
|
@@ -1,8 +1,12 @@
|
|
|
1
|
-
先ほどは早合点して申し訳
|
|
1
|
+
先ほどは早合点して申し訳ございませんでした。
|
|
2
|
+
|
|
3
|
+
話の趣旨が変わるため、別で回答します。
|
|
2
4
|
|
|
3
5
|
|
|
4
6
|
|
|
5
7
|
`UnhandledException`で補足されない例外は**.NET Framework の内部処理で発生する例外**だと思います。
|
|
8
|
+
|
|
9
|
+
詳しい例外の話については、[.NET Framework の内部処理で発生する例外について](https://blogs.msdn.microsoft.com/jpvsblog/2014/09/16/net-framework/)が参考になるかもしれません。
|
|
6
10
|
|
|
7
11
|
|
|
8
12
|
|
|
@@ -20,8 +24,4 @@
|
|
|
20
24
|
|
|
21
25
|
補足されなかった例外は基本的にイベントログで確認できます。
|
|
22
26
|
|
|
23
|
-
可能なら、そこでエラーの内容を確認できると
|
|
27
|
+
可能なら、そこでエラーの内容を確認できると原因を調査できるかもしれません。
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
詳しい例外の話については、[.NET Framework の内部処理で発生する例外について](https://blogs.msdn.microsoft.com/jpvsblog/2014/09/16/net-framework/)をご覧になると参考になるかもしれません。
|