C++/CLIでデバッグ実行中に、delete_scalar.cpp　という画面が出て例外が発生する

対応策を云々する前に、この例外が「誤検知」であるかどうかを確認しておいた方が良いのでは？

(再現環境さえあれば、瞬殺で確認できます。)

参考までに確認手順を示しておきます。

(下記説明は、質問者さんが示したコードを前提としています。)

<"test1" の確認手順>

1. 該当プログラムをデバッガ上から実行させ、例外を発生させる。(例外で止まっている状態。)
2. Visual Studio デバッガを使用している場合は、[呼び出し履歴] (コール スタック) ウィンドウでの表示で、最上位が "プロフラム.exe!_free_dbg(...)" になっているのを確認する。
3. コール スタックの最上位が "プロフラム.exe!_free_dbg(...)" になっている場合、その [呼び出し履歴] リストの中に delete 演算子を呼び出した自分の関数が存在するはずなので、それをクリックする。
4. Visual Studio デバッガの [ローカル] ウィンドウに test1 のアドレスが表示されているはずなので、それを確認する。
5. [ローカル] ウィンドウ test1 アドレスと、[呼び出し履歴] ウィンドウ _free_dbg() の block アドレスが一致していることを確認する。
6. Visual Studio [呼び出し履歴] ウィンドウ タブの隣にある [コマンド ウィンドウ] に切り替え、dq コマンドで test1 の中身を確認する。

例えば上記 3 でのコール スタック最上位の表示が

"プロフラム.exe!_free_dbg(void * block=0x00000216d238cc80, int block_use=0xffffffff)"

となっていた場合、test1 配列の先頭アドレスは 0x00000216d238cc80 になります。

ここで [呼び出し履歴] ウィンドウから [コマンド ウィンドウ] に切り替え、メモリ 0x00000216d238cc80 の中身を確認すればいい。。。ということです。

「誤検知」である場合は、下記のように test1[0] には 0x0000000000000009 がセットされていることが確認できるはずです。

dq 0x00000216d238cc80

0x00000216D238CC80 0000000000000009 cdcdcdcdcdcdcdcd

御回答ありがとうございます。

誤検知であるかどうかにかかわらず、デバッガーで何か検知動作が行われて例外が発生したということは、私が示した簡単なコードの部分以外の動作でも異常動作の監視が行われていることになると思います。そこまで監視動作をキャンセルしてしまうのも問題有りだと思います。

従って、既にmalloc()を使ってスマートに解決しました。

こんな返信してももぅ意味ないのかもしれませんが、勘違いしているようなので一応。。。。

下記は質問者さんが提示したコードで、malloc 関数にブレークポイントを設定したときのコール スタックです。

(これを見て何も思わないなら、それはそれでいいですけど。)

0:000> k
 # Child-SP          RetAddr               Call Site
00 0000009c`8f9efaa8 00007ff6`b1995ec3     hoge!malloc [minkernel\crts\ucrt\src\appcrt\heap\malloc.cpp @ 21] 
01 0000009c`8f9efab0 00007ff6`b19951a3     hoge!operator new+0x13 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\heap\new_scalar.cpp @ 35] 
02 0000009c`8f9efaf0 00007ff6`b1994f39     hoge!operator new[]+0x13 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\heap\new_array.cpp @ 29] 
03 0000009c`8f9efb20 00007ff6`b1995e34     hoge!wmain+0x59
04 0000009c`8f9efb80 00007ff6`b1995d5e     hoge!invoke_main+0x34 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 91] 
05 0000009c`8f9efbc0 00007ff6`b1995c1e     hoge!__scrt_common_main_seh+0x12e [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
06 0000009c`8f9efc30 00007ff6`b1995ea9     hoge!__scrt_common_main+0xe [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 331] 
07 0000009c`8f9efc60 00007ffc`56837374     hoge!wmainCRTStartup+0x9 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_wmain.cpp @ 17] 
08 0000009c`8f9efc90 00007ffc`576fcc91     KERNEL32!BaseThreadInitThunk+0x14
09 0000009c`8f9efcc0 00000000`00000000     ntdll!RtlUserThreadStart+0x21

すみません。何も理解できる用語がこの中にありません。独学でこのような低い知識レベルです。ご理解ください。

先に示したコール スタックでは、new [] 演算子でも最終的には malloc() コールにより、ヒープ領域からのメモリ割り当てを行っている事を示しています。

つまり new [] 演算子から malloc() に置き換えたところで、本質的な問題は何も解決されず、臭い物に蓋をしただけ。。。ということではないかと。

色々教えていただきありがとうございます。

int ii=9;

float* test1 = new float[ii];//例外発生

delete[] test1;

これはネットに掲載されていたサンプルプログラムと構造的には変わりません。

これでも例外が発生します。

このコードでも本質的な問題とおっしゃるのでしたら、何が問題か教えて下さい。

ほかの方の開発環境では動作が再現しないというのは理解できております。

こちらでは、ソリューションを新規作成しても同じ例外が出ます。

VS2019を更新インストールしても同じ状況です。