gummoni
commented
1 year ago 57 の問題と共通しているかもしれまんせんが、
例外が発生したときにデバッガ上にある呼び出し履歴では追跡できないという症状を推察すると、 UIコンポーネントのプロパティが、UIスレッド以外の別スレッドにて書き換えが行われたことで UIスレッド内で例外が発生していると考えられます。 この例外をキャッチするにはApp.xamlの部分でTry～Catchできれば御の字で、キャッチできなかった場合は 以下のような方法で追跡します。
今回のUIスレッドから発生する例外でMAUIの場合 razorクラスで参照しているプロパティを別スレッドで操作しないようにする必要があります。
デバッグする手順は、 １．どのような操作したときに例外が発生したのか再現手順を確立する。 ２．影響範囲を絞る。 ３．１つずつ機能を削って問題の箇所を探っていく。 ４．画面表示しているプロパティ、副作用のある変数、発生するイベント（PropertyChangeNotifyなど）を調べる。
追跡するにはスレッド単位やユーザ操作単位など複数の視点で ・ユーザ視点で発生イベントから追跡 ・システム視点でＵＩスレッドの画面の変化や使用している要素（プロパティ）から追跡 ・他バックグラウンドで動いているスレッド単位で追跡
を行っていきます。 今回はView側で「UIスレッド以外の別スレッドでプロパティ操作が行われた」という事を念頭に調査すると 大体のポイントが見えてきます。
「人」タブでカードにクリックしたから、「編集」ボタンをクリックすると、エラーが起きます。
https://user-images.githubusercontent.com/41653501/259932648-81dea143-6656-4844-9f96-014d77b75ccd.mp4
スタックトレースを見ると、「外部コード」しか書いていないです。
（もしカードをクリックした時点で例外が投げられたか、西野さんは「依頼されていないデバッグでの停止」イッシュー）を再現出来た訳です。
「外部コード」だけでデバッグできません。
このイッシューの目的はデバッグを代行してもらうのではなく、例外が投げられるところに参考している出力をどこで見れるか、教えてもらう事です。 どれのクラスのせいぐらい知っていますが、次回は知るのは限らないので、出力の中にヒントを探す能力をつけなければいけません。尚、クラスが大きさがいくらでも大きいので、クラスだけ知る事は足りなく、メソッドまで知る必要があります。