Exceptions while using MiniDumpWriteDump() Win32 API while debuging










0















I spawn a process "2" from a process "1" in C++/CLI. While both are running, process "1" kills process "2" (by design). My goal is to produce a mini dump of "2" just before killing it.



Here is my code:



// mpProcess started with System::Diagnostics::Process... etc.
System::IO::FileStream^ fs = gcnew System::IO::FileStream("MyPath.dmp");

MiniDumpWriteDump( mpProcess->Handle.ToPointer(), mpProcess->Id, fs->SafeFileHandle->DangerousGetHandle().ToPointer(), MINIDUMP_TYPE::MiniDumpNormal, nullptr, nullptr, nullptr);
fs->Close();


When I start process "1" from a command line, without attaching it to the debugger, it runs normally, starts process "2" then dumps it then kills it.



When I start process "1" in the debugger, I get 2-3 AccessViolationException when I step over the call to MiniDumpWriteDump, but if I click onto "Continue" everything goes fine and the dump file is produced.



What is going on? Is there something wrong in my design? Notice that it is the first time I use this API, I didn't even know I could dump such a file 24 hours ago ;-) ! I will be grateful for your kind help to improve my skills with dump files.



EDIT 1 Added Exception information:



Here is the message I got:



Exception thrown at 0x000007FED860FD31 (mscordacwks.dll) in MYProg.exe: 0xC0000005: Access violation reading location 0x0000000000000000.



If there is a handler for this exception, the program may be safely continued.



EDIT 2 Added a snippet and a stack trace



Process 1: The "killer"



// Process1.cpp : main project file.

#include "stdafx.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <dbghelp.h>

using namespace System;

int main(array<System::String ^> ^args)

Console::WriteLine(L"Hello, I'm Process1! I'll "minidump" Process2 then kill it!");

System::Diagnostics::Process^ p = gcnew System::Diagnostics::Process();

p->StartInfo->FileName = "Process2.exe";
p->Start();

System::Threading::Thread::Sleep( 3000 );

System::IO::FileStream^ fs = gcnew System::IO::FileStream( "minidump.dmp", System::IO::FileMode::Create );

MiniDumpWriteDump( p->Handle.ToPointer(), p->Id, fs->SafeFileHandle->DangerousGetHandle().ToPointer(), MINIDUMP_TYPE::MiniDumpNormal, nullptr, nullptr, nullptr );

fs->Close();

p->Kill();

return 0;



Process 2: the "dumped"



// Process2.cpp : main project file.

#include "stdafx.h"

using namespace System;

int main(array<System::String ^> ^args)

Console::WriteLine(L"Hello, I'm Process2! I'm waiting to be killed by Process1!");

// Do nothing, wait to be killed
while ( true )

System::Threading::Thread::Sleep( 1000 );


return 0;



Stack trace when I break it from within the (AccessViolation)Exception dialog:



mscordacwks.dll!000007fed860fd31() Unknown
mscordacwks.dll!000007fed861028c() Unknown
mscordacwks.dll!000007fed8610fd2() Unknown
mscordacwks.dll!000007fed861165f() Unknown
mscordacwks.dll!000007fed861176e() Unknown
dbghelp.dll!GenGetAuxMemory(struct _MINIDUMP_STATE *,struct _INTERNAL_PROCESS *) Unknown
dbghelp.dll!GenGetProcessInfo(struct _MINIDUMP_STATE *,struct _INTERNAL_PROCESS * *) Unknown
dbghelp.dll!MiniDumpProvideDump() Unknown
dbghelp.dll!MiniDumpWriteDump() Unknown
[Managed to Native Transition]
[CURSOR]>>> Process1.exe!main(array<System::String^>^ args=array<System::String^>(0)) Line 24 C++
Process1.exe!mainCRTStartupStrArray(array<System::String^>^ arguments=array<System::String^>(0)) Line 249 C++
[Native to Managed Transition]
mscoreei.dll!000007feee467a6d() Unknown
mscoree.dll!_CorExeMain_Exported() Unknown
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown









share|improve this question
























  • @HansPassant See my Edit 2. You'll find a snippet of both apps and the stack trace when it breaks on exception. Note: VS 2015 Update 3 if it can help...

    – dom_beau
    Nov 13 '18 at 16:27











  • @HansPassant ...also note: created from scratch so stdafx.h/.cpp, AssemblyInfo.cpp etc are auto created by VS. I did not modify them...

    – dom_beau
    Nov 13 '18 at 16:29











  • @HansPassant dbghelp.dll: 6.1.7601.17514; both my apps were created on the same system/solution one after the other. The platform target is 8.1, the .NET is 4.6.1.

    – dom_beau
    Nov 13 '18 at 16:55











  • That is ancient Win7. Do you have any memory of using a recent SDK version of dbghelp.dll? Do you have a local copy of it? Double-check with the debugger's Debug > Windows > Modules window, it shows the actual dbghelp.dll that got loaded. I meant platform as in x64 vs Win32/x86.

    – Hans Passant
    Nov 13 '18 at 17:06







  • 1





    I don't think you have a real problem, just the debugger showing you more than you bargained for. DbgHelp knows how to take a lickin' and keep on tickin'. Root cause is surely a very old version of dbghelp.dll probing a very new version of the CLR. I have no good way to verify that.

    – Hans Passant
    Nov 13 '18 at 17:56















0















I spawn a process "2" from a process "1" in C++/CLI. While both are running, process "1" kills process "2" (by design). My goal is to produce a mini dump of "2" just before killing it.



Here is my code:



// mpProcess started with System::Diagnostics::Process... etc.
System::IO::FileStream^ fs = gcnew System::IO::FileStream("MyPath.dmp");

MiniDumpWriteDump( mpProcess->Handle.ToPointer(), mpProcess->Id, fs->SafeFileHandle->DangerousGetHandle().ToPointer(), MINIDUMP_TYPE::MiniDumpNormal, nullptr, nullptr, nullptr);
fs->Close();


When I start process "1" from a command line, without attaching it to the debugger, it runs normally, starts process "2" then dumps it then kills it.



When I start process "1" in the debugger, I get 2-3 AccessViolationException when I step over the call to MiniDumpWriteDump, but if I click onto "Continue" everything goes fine and the dump file is produced.



What is going on? Is there something wrong in my design? Notice that it is the first time I use this API, I didn't even know I could dump such a file 24 hours ago ;-) ! I will be grateful for your kind help to improve my skills with dump files.



EDIT 1 Added Exception information:



Here is the message I got:



Exception thrown at 0x000007FED860FD31 (mscordacwks.dll) in MYProg.exe: 0xC0000005: Access violation reading location 0x0000000000000000.



If there is a handler for this exception, the program may be safely continued.



EDIT 2 Added a snippet and a stack trace



Process 1: The "killer"



// Process1.cpp : main project file.

#include "stdafx.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <dbghelp.h>

using namespace System;

int main(array<System::String ^> ^args)

Console::WriteLine(L"Hello, I'm Process1! I'll "minidump" Process2 then kill it!");

System::Diagnostics::Process^ p = gcnew System::Diagnostics::Process();

p->StartInfo->FileName = "Process2.exe";
p->Start();

System::Threading::Thread::Sleep( 3000 );

System::IO::FileStream^ fs = gcnew System::IO::FileStream( "minidump.dmp", System::IO::FileMode::Create );

MiniDumpWriteDump( p->Handle.ToPointer(), p->Id, fs->SafeFileHandle->DangerousGetHandle().ToPointer(), MINIDUMP_TYPE::MiniDumpNormal, nullptr, nullptr, nullptr );

fs->Close();

p->Kill();

return 0;



Process 2: the "dumped"



// Process2.cpp : main project file.

#include "stdafx.h"

using namespace System;

int main(array<System::String ^> ^args)

Console::WriteLine(L"Hello, I'm Process2! I'm waiting to be killed by Process1!");

// Do nothing, wait to be killed
while ( true )

System::Threading::Thread::Sleep( 1000 );


return 0;



Stack trace when I break it from within the (AccessViolation)Exception dialog:



mscordacwks.dll!000007fed860fd31() Unknown
mscordacwks.dll!000007fed861028c() Unknown
mscordacwks.dll!000007fed8610fd2() Unknown
mscordacwks.dll!000007fed861165f() Unknown
mscordacwks.dll!000007fed861176e() Unknown
dbghelp.dll!GenGetAuxMemory(struct _MINIDUMP_STATE *,struct _INTERNAL_PROCESS *) Unknown
dbghelp.dll!GenGetProcessInfo(struct _MINIDUMP_STATE *,struct _INTERNAL_PROCESS * *) Unknown
dbghelp.dll!MiniDumpProvideDump() Unknown
dbghelp.dll!MiniDumpWriteDump() Unknown
[Managed to Native Transition]
[CURSOR]>>> Process1.exe!main(array<System::String^>^ args=array<System::String^>(0)) Line 24 C++
Process1.exe!mainCRTStartupStrArray(array<System::String^>^ arguments=array<System::String^>(0)) Line 249 C++
[Native to Managed Transition]
mscoreei.dll!000007feee467a6d() Unknown
mscoree.dll!_CorExeMain_Exported() Unknown
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown









share|improve this question
























  • @HansPassant See my Edit 2. You'll find a snippet of both apps and the stack trace when it breaks on exception. Note: VS 2015 Update 3 if it can help...

    – dom_beau
    Nov 13 '18 at 16:27











  • @HansPassant ...also note: created from scratch so stdafx.h/.cpp, AssemblyInfo.cpp etc are auto created by VS. I did not modify them...

    – dom_beau
    Nov 13 '18 at 16:29











  • @HansPassant dbghelp.dll: 6.1.7601.17514; both my apps were created on the same system/solution one after the other. The platform target is 8.1, the .NET is 4.6.1.

    – dom_beau
    Nov 13 '18 at 16:55











  • That is ancient Win7. Do you have any memory of using a recent SDK version of dbghelp.dll? Do you have a local copy of it? Double-check with the debugger's Debug > Windows > Modules window, it shows the actual dbghelp.dll that got loaded. I meant platform as in x64 vs Win32/x86.

    – Hans Passant
    Nov 13 '18 at 17:06







  • 1





    I don't think you have a real problem, just the debugger showing you more than you bargained for. DbgHelp knows how to take a lickin' and keep on tickin'. Root cause is surely a very old version of dbghelp.dll probing a very new version of the CLR. I have no good way to verify that.

    – Hans Passant
    Nov 13 '18 at 17:56













0












0








0








I spawn a process "2" from a process "1" in C++/CLI. While both are running, process "1" kills process "2" (by design). My goal is to produce a mini dump of "2" just before killing it.



Here is my code:



// mpProcess started with System::Diagnostics::Process... etc.
System::IO::FileStream^ fs = gcnew System::IO::FileStream("MyPath.dmp");

MiniDumpWriteDump( mpProcess->Handle.ToPointer(), mpProcess->Id, fs->SafeFileHandle->DangerousGetHandle().ToPointer(), MINIDUMP_TYPE::MiniDumpNormal, nullptr, nullptr, nullptr);
fs->Close();


When I start process "1" from a command line, without attaching it to the debugger, it runs normally, starts process "2" then dumps it then kills it.



When I start process "1" in the debugger, I get 2-3 AccessViolationException when I step over the call to MiniDumpWriteDump, but if I click onto "Continue" everything goes fine and the dump file is produced.



What is going on? Is there something wrong in my design? Notice that it is the first time I use this API, I didn't even know I could dump such a file 24 hours ago ;-) ! I will be grateful for your kind help to improve my skills with dump files.



EDIT 1 Added Exception information:



Here is the message I got:



Exception thrown at 0x000007FED860FD31 (mscordacwks.dll) in MYProg.exe: 0xC0000005: Access violation reading location 0x0000000000000000.



If there is a handler for this exception, the program may be safely continued.



EDIT 2 Added a snippet and a stack trace



Process 1: The "killer"



// Process1.cpp : main project file.

#include "stdafx.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <dbghelp.h>

using namespace System;

int main(array<System::String ^> ^args)

Console::WriteLine(L"Hello, I'm Process1! I'll "minidump" Process2 then kill it!");

System::Diagnostics::Process^ p = gcnew System::Diagnostics::Process();

p->StartInfo->FileName = "Process2.exe";
p->Start();

System::Threading::Thread::Sleep( 3000 );

System::IO::FileStream^ fs = gcnew System::IO::FileStream( "minidump.dmp", System::IO::FileMode::Create );

MiniDumpWriteDump( p->Handle.ToPointer(), p->Id, fs->SafeFileHandle->DangerousGetHandle().ToPointer(), MINIDUMP_TYPE::MiniDumpNormal, nullptr, nullptr, nullptr );

fs->Close();

p->Kill();

return 0;



Process 2: the "dumped"



// Process2.cpp : main project file.

#include "stdafx.h"

using namespace System;

int main(array<System::String ^> ^args)

Console::WriteLine(L"Hello, I'm Process2! I'm waiting to be killed by Process1!");

// Do nothing, wait to be killed
while ( true )

System::Threading::Thread::Sleep( 1000 );


return 0;



Stack trace when I break it from within the (AccessViolation)Exception dialog:



mscordacwks.dll!000007fed860fd31() Unknown
mscordacwks.dll!000007fed861028c() Unknown
mscordacwks.dll!000007fed8610fd2() Unknown
mscordacwks.dll!000007fed861165f() Unknown
mscordacwks.dll!000007fed861176e() Unknown
dbghelp.dll!GenGetAuxMemory(struct _MINIDUMP_STATE *,struct _INTERNAL_PROCESS *) Unknown
dbghelp.dll!GenGetProcessInfo(struct _MINIDUMP_STATE *,struct _INTERNAL_PROCESS * *) Unknown
dbghelp.dll!MiniDumpProvideDump() Unknown
dbghelp.dll!MiniDumpWriteDump() Unknown
[Managed to Native Transition]
[CURSOR]>>> Process1.exe!main(array<System::String^>^ args=array<System::String^>(0)) Line 24 C++
Process1.exe!mainCRTStartupStrArray(array<System::String^>^ arguments=array<System::String^>(0)) Line 249 C++
[Native to Managed Transition]
mscoreei.dll!000007feee467a6d() Unknown
mscoree.dll!_CorExeMain_Exported() Unknown
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown









share|improve this question
















I spawn a process "2" from a process "1" in C++/CLI. While both are running, process "1" kills process "2" (by design). My goal is to produce a mini dump of "2" just before killing it.



Here is my code:



// mpProcess started with System::Diagnostics::Process... etc.
System::IO::FileStream^ fs = gcnew System::IO::FileStream("MyPath.dmp");

MiniDumpWriteDump( mpProcess->Handle.ToPointer(), mpProcess->Id, fs->SafeFileHandle->DangerousGetHandle().ToPointer(), MINIDUMP_TYPE::MiniDumpNormal, nullptr, nullptr, nullptr);
fs->Close();


When I start process "1" from a command line, without attaching it to the debugger, it runs normally, starts process "2" then dumps it then kills it.



When I start process "1" in the debugger, I get 2-3 AccessViolationException when I step over the call to MiniDumpWriteDump, but if I click onto "Continue" everything goes fine and the dump file is produced.



What is going on? Is there something wrong in my design? Notice that it is the first time I use this API, I didn't even know I could dump such a file 24 hours ago ;-) ! I will be grateful for your kind help to improve my skills with dump files.



EDIT 1 Added Exception information:



Here is the message I got:



Exception thrown at 0x000007FED860FD31 (mscordacwks.dll) in MYProg.exe: 0xC0000005: Access violation reading location 0x0000000000000000.



If there is a handler for this exception, the program may be safely continued.



EDIT 2 Added a snippet and a stack trace



Process 1: The "killer"



// Process1.cpp : main project file.

#include "stdafx.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <dbghelp.h>

using namespace System;

int main(array<System::String ^> ^args)

Console::WriteLine(L"Hello, I'm Process1! I'll "minidump" Process2 then kill it!");

System::Diagnostics::Process^ p = gcnew System::Diagnostics::Process();

p->StartInfo->FileName = "Process2.exe";
p->Start();

System::Threading::Thread::Sleep( 3000 );

System::IO::FileStream^ fs = gcnew System::IO::FileStream( "minidump.dmp", System::IO::FileMode::Create );

MiniDumpWriteDump( p->Handle.ToPointer(), p->Id, fs->SafeFileHandle->DangerousGetHandle().ToPointer(), MINIDUMP_TYPE::MiniDumpNormal, nullptr, nullptr, nullptr );

fs->Close();

p->Kill();

return 0;



Process 2: the "dumped"



// Process2.cpp : main project file.

#include "stdafx.h"

using namespace System;

int main(array<System::String ^> ^args)

Console::WriteLine(L"Hello, I'm Process2! I'm waiting to be killed by Process1!");

// Do nothing, wait to be killed
while ( true )

System::Threading::Thread::Sleep( 1000 );


return 0;



Stack trace when I break it from within the (AccessViolation)Exception dialog:



mscordacwks.dll!000007fed860fd31() Unknown
mscordacwks.dll!000007fed861028c() Unknown
mscordacwks.dll!000007fed8610fd2() Unknown
mscordacwks.dll!000007fed861165f() Unknown
mscordacwks.dll!000007fed861176e() Unknown
dbghelp.dll!GenGetAuxMemory(struct _MINIDUMP_STATE *,struct _INTERNAL_PROCESS *) Unknown
dbghelp.dll!GenGetProcessInfo(struct _MINIDUMP_STATE *,struct _INTERNAL_PROCESS * *) Unknown
dbghelp.dll!MiniDumpProvideDump() Unknown
dbghelp.dll!MiniDumpWriteDump() Unknown
[Managed to Native Transition]
[CURSOR]>>> Process1.exe!main(array<System::String^>^ args=array<System::String^>(0)) Line 24 C++
Process1.exe!mainCRTStartupStrArray(array<System::String^>^ arguments=array<System::String^>(0)) Line 249 C++
[Native to Managed Transition]
mscoreei.dll!000007feee467a6d() Unknown
mscoree.dll!_CorExeMain_Exported() Unknown
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown






.net c++-cli dump minidump minidumpwritedump






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 13 '18 at 16:24







dom_beau

















asked Nov 13 '18 at 13:41









dom_beaudom_beau

95821343




95821343












  • @HansPassant See my Edit 2. You'll find a snippet of both apps and the stack trace when it breaks on exception. Note: VS 2015 Update 3 if it can help...

    – dom_beau
    Nov 13 '18 at 16:27











  • @HansPassant ...also note: created from scratch so stdafx.h/.cpp, AssemblyInfo.cpp etc are auto created by VS. I did not modify them...

    – dom_beau
    Nov 13 '18 at 16:29











  • @HansPassant dbghelp.dll: 6.1.7601.17514; both my apps were created on the same system/solution one after the other. The platform target is 8.1, the .NET is 4.6.1.

    – dom_beau
    Nov 13 '18 at 16:55











  • That is ancient Win7. Do you have any memory of using a recent SDK version of dbghelp.dll? Do you have a local copy of it? Double-check with the debugger's Debug > Windows > Modules window, it shows the actual dbghelp.dll that got loaded. I meant platform as in x64 vs Win32/x86.

    – Hans Passant
    Nov 13 '18 at 17:06







  • 1





    I don't think you have a real problem, just the debugger showing you more than you bargained for. DbgHelp knows how to take a lickin' and keep on tickin'. Root cause is surely a very old version of dbghelp.dll probing a very new version of the CLR. I have no good way to verify that.

    – Hans Passant
    Nov 13 '18 at 17:56

















  • @HansPassant See my Edit 2. You'll find a snippet of both apps and the stack trace when it breaks on exception. Note: VS 2015 Update 3 if it can help...

    – dom_beau
    Nov 13 '18 at 16:27











  • @HansPassant ...also note: created from scratch so stdafx.h/.cpp, AssemblyInfo.cpp etc are auto created by VS. I did not modify them...

    – dom_beau
    Nov 13 '18 at 16:29











  • @HansPassant dbghelp.dll: 6.1.7601.17514; both my apps were created on the same system/solution one after the other. The platform target is 8.1, the .NET is 4.6.1.

    – dom_beau
    Nov 13 '18 at 16:55











  • That is ancient Win7. Do you have any memory of using a recent SDK version of dbghelp.dll? Do you have a local copy of it? Double-check with the debugger's Debug > Windows > Modules window, it shows the actual dbghelp.dll that got loaded. I meant platform as in x64 vs Win32/x86.

    – Hans Passant
    Nov 13 '18 at 17:06







  • 1





    I don't think you have a real problem, just the debugger showing you more than you bargained for. DbgHelp knows how to take a lickin' and keep on tickin'. Root cause is surely a very old version of dbghelp.dll probing a very new version of the CLR. I have no good way to verify that.

    – Hans Passant
    Nov 13 '18 at 17:56
















@HansPassant See my Edit 2. You'll find a snippet of both apps and the stack trace when it breaks on exception. Note: VS 2015 Update 3 if it can help...

– dom_beau
Nov 13 '18 at 16:27





@HansPassant See my Edit 2. You'll find a snippet of both apps and the stack trace when it breaks on exception. Note: VS 2015 Update 3 if it can help...

– dom_beau
Nov 13 '18 at 16:27













@HansPassant ...also note: created from scratch so stdafx.h/.cpp, AssemblyInfo.cpp etc are auto created by VS. I did not modify them...

– dom_beau
Nov 13 '18 at 16:29





@HansPassant ...also note: created from scratch so stdafx.h/.cpp, AssemblyInfo.cpp etc are auto created by VS. I did not modify them...

– dom_beau
Nov 13 '18 at 16:29













@HansPassant dbghelp.dll: 6.1.7601.17514; both my apps were created on the same system/solution one after the other. The platform target is 8.1, the .NET is 4.6.1.

– dom_beau
Nov 13 '18 at 16:55





@HansPassant dbghelp.dll: 6.1.7601.17514; both my apps were created on the same system/solution one after the other. The platform target is 8.1, the .NET is 4.6.1.

– dom_beau
Nov 13 '18 at 16:55













That is ancient Win7. Do you have any memory of using a recent SDK version of dbghelp.dll? Do you have a local copy of it? Double-check with the debugger's Debug > Windows > Modules window, it shows the actual dbghelp.dll that got loaded. I meant platform as in x64 vs Win32/x86.

– Hans Passant
Nov 13 '18 at 17:06






That is ancient Win7. Do you have any memory of using a recent SDK version of dbghelp.dll? Do you have a local copy of it? Double-check with the debugger's Debug > Windows > Modules window, it shows the actual dbghelp.dll that got loaded. I meant platform as in x64 vs Win32/x86.

– Hans Passant
Nov 13 '18 at 17:06





1




1





I don't think you have a real problem, just the debugger showing you more than you bargained for. DbgHelp knows how to take a lickin' and keep on tickin'. Root cause is surely a very old version of dbghelp.dll probing a very new version of the CLR. I have no good way to verify that.

– Hans Passant
Nov 13 '18 at 17:56





I don't think you have a real problem, just the debugger showing you more than you bargained for. DbgHelp knows how to take a lickin' and keep on tickin'. Root cause is surely a very old version of dbghelp.dll probing a very new version of the CLR. I have no good way to verify that.

– Hans Passant
Nov 13 '18 at 17:56












0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53282342%2fexceptions-while-using-minidumpwritedump-win32-api-while-debuging%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53282342%2fexceptions-while-using-minidumpwritedump-win32-api-while-debuging%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







這個網誌中的熱門文章

How to read a connectionString WITH PROVIDER in .NET Core?

In R, how to develop a multiplot heatmap.2 figure showing key labels successfully

Museum of Modern and Contemporary Art of Trento and Rovereto