関数のシグネチャは非常に面倒です。コードがクラッシュするかどうかは、実行しているオペレーティングシステムによって異なります。XPでは何も起こりません。Vista以降ではAccessViolation例外がスローされます。
問題は、文字列を返すC関数は通常、文字列を格納するバッファへのポインタを返すことによってそうする必要があるということです。そのバッファはヒープから割り当てる必要があり、呼び出し元は文字列を使用した後にそのバッファを解放する必要があります。pinvokeマーシャラーはそのコントラクトを実装し、System.Stringに変換した後、返された文字列ポインターでCoTaskMemFree()を呼び出します。
それは常にうまくいかず、C関数がCoTaskMemAlloc()を使用してバッファーを割り当てることはほとんどありません。XPヒープマネージャは非常に寛容であり、単に不正なポインタを無視します。それ以降のWindowsバージョンではなく、意図的に例外を生成します。「Vistasucks」ラベルの強力なイネーブラーですが、プログラマーがポインターのバグを修正するのにしばらく時間がかかりました。アンマネージデバッグを有効にしている場合は、ヒープマネージャーから、ポインターが無効であることを警告する診断が表示されます。非常に優れた機能ですが、マネージコードをデバッグする場合、アンマネージデバッグは常に無効になります。
戻り値をIntPtrとして宣言することにより、pinvokeマーシャラーが文字列を解放しようとするのを防ぐことができます。次に、Marshal.PtrToStringAnsi()またはその友人の1人を使用して文字列を自分でマーシャリングする必要があります。
あなたはまだ文字列バッファを解放しなければならないという問題を抱えています。これを確実に行う方法はありません。適切なデアロケーターを呼び出すことはできません。唯一の希望は、C関数が実際に文字列リテラルへのポインタを返すことです。文字列リテラルはデータセグメントに格納されているため、解放しないでください。これは、ローカリゼーションのような凝ったものを実装していなければ、エラー文字列を返す関数で機能する可能性があります。constchar*リターン型は有望です。
これをテストして、文字列バッファを解放しないことによるメモリリークがないことを確認する必要があります。簡単に実行できます。この関数をループで10億回呼び出します。IntPtr.Zeroを戻り値として取得せず、プログラムがメモリ不足の例外でフォールオーバーしない場合は、問題ありません。64ビットのピンボークの場合、テストプログラムのメモリ消費量を監視する必要があります。