Visual Studio 2022 Part3 (791ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
420(1): (ｵｲｺﾗﾐﾈｵ MM1f-b23o) 2024/10/06(日)22:36 ID:d04aHUxEM(1/7)調 AAS
>>416
必要なのは逆さま。
アプリの生成フォルダのDebugフォルダに、
*.dll をコピーする必要が有る。
そうしないと無理。
421: (ｵｲｺﾗﾐﾈｵ MM1f-b23o) 2024/10/06(日)22:37 ID:d04aHUxEM(2/7)調 AAS
>>420
理由は、アプリの*.exeと*.cppの相対位置を変えると
デバッガが混乱しやすいことにも有る。
422: (ｵｲｺﾗﾐﾈｵ MM1f-b23o) 2024/10/06(日)22:43 ID:d04aHUxEM(3/7)調 AAS
>>419
HelloWorld的な簡単なアプリでAttach法で
上手くデバッグできることは試してみた？
423(2): (ｵｲｺﾗﾐﾈｵ MM1f-b23o) 2024/10/06(日)22:59 ID:d04aHUxEM(4/7)調 AAS
>>417
なるほどね。
それは、アプリにBreakPointをかけても、デバッガに
ソースがないと言われるのは当然ですわ。
その場合、Attachではなく、そのexeをデバッガ経由で
デバッグ起動すると少しましになる可能性が有る。
なぜかというと、デバッガがDLLの起動時にイベントを
受け取り、どんなDLLがロードされたかを知ることが
できるようになるから。
424(2): (ｵｲｺﾗﾐﾈｵ MM1f-b23o) 2024/10/06(日)23:02 ID:d04aHUxEM(5/7)調 AAS
>>423
Attach法だと、デバッガが接続されるのは、
DLLがロードされた後になってしまい、
DLLがロード時に発生するイベントをデバッガが
捕捉することが出来ない。
そのため、ロードされたDLLの名前や場所などの
情報をデバッガが知る事が難しい状況に
なる。
DLLにソースが有る場合、
DLLがどこにあるかが分かれば、DLLの中に対しては
BreakPointなどを仕掛けることが出来る可能性が
まだ残っている。
425: (ｵｲｺﾗﾐﾈｵ MM1f-b23o) 2024/10/06(日)23:05 ID:d04aHUxEM(6/7)調 AAS
>>424
DLLの中の関数のアドレスが分かれば、デバッガは
そこにBreakPointを仕掛けることは可能。
ソースがあれば、アドレスに対応する場所のソースを見ることも可能。
大事なのは、デバッガにDLLの種類とソースの場所などを
知らせることだ。
426(1): (ｵｲｺﾗﾐﾈｵ MM1f-b23o) 2024/10/06(日)23:10 ID:d04aHUxEM(7/7)調 AAS
簡単に言えば、
その*.exeをVisualStudioにDrag&Dropしてから、
「デバッグを開始」を選ぶと、少し好転するかも
知れないということだ。
DLLのソースは有るんだよね？
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s