Why does taking a snapshot kill the process being profiled?

SamNabialek

The process was built using VS 2019 and Postsharp 6.6.10. It targets .NET 4.0 running under Win 10 Enterprise.

I click on take a snapshot and get a pop-up telling me that the process has stopped working. I tried leaving it for 10 minutes, but nothing changed.

Any idea why I cannot profile what is a simple process? I took out the GUI and had the whole thing running under a simple command line. The process is single threaded with no async operations. I'm trying to track a leak in a library - the process is as simple a wrapper as I can put around the library to call into its functionality.

Am I being hasty in killing the process?

For the record. Using the default settings for a profiling session.

===Update===

It seems to be windows killing the process about 20 seconds into the snapshot. I assume that the process freezes the running thread until the GUI is answered. If anyone knows a way to stop windows killing the process so quickly - that would be a help.

Jessica R

Hi @SamNabialek,

Are there any errors in Event Viewer>Windows log>Application after this happens?

SamNabialek

Hi,  Jessica,

First Error is:

Application: Sandbox.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFD8263B1AD (00007FFD82040000) with exit code 80131506.

Second is:

Faulting application name: Sandbox.exe, version: 1.0.0.8255, time stamp: 0x5f0ffae7
Faulting module name: clr.dll, version: 4.8.4180.0, time stamp: 0x5e7d21b3
Exception code: 0xc0000005
Fault offset: 0x00000000005fb1ad
Faulting process id: 0x1560c
Faulting application start time: 0x01d65b3eba549617
Faulting application path: T:\SRC\Core\Compiler\CompilerGUI\1.0.0\Bin\Sandbox.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: a3c86782-f82a-4bbb-bf99-9bb86c73214a
Faulting package full name:

Faulting package-relative application ID:

Subsequent Information is:

Fault bucket 1904641844225617697, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: Sandbox.exe
P2: 1.0.0.8255
P3: 5f0ffae7
P4: clr.dll
P5: 4.8.4180.0
P6: 5e7d21b3
P7: c0000005
P8: 00000000005fb1ad
P9:
P10:

Help any?

Jessica R

Thanks @SamNabialek!

Hm, the exit code 80131506 can be difficult to troubleshoot unfortunately.

Can I please check:

- Does the issue remain if you disable the option, "Profile unmanaged memory allocations"?
- Does it remain if you disable "Profile child processes"?
- Does enabling "Make snapshots faster..." prevent the issue?
- Do you still get the crash if you profile by attaching to process?

SamNabialek

HI, Jessica,

The issue remains until I switch to the attach mode of operation.  It did require me to make the process sleep for 60 seconds so I could attach to the process in time to take the first important snapshot. Other than that, it seems to be working fine.

Does that help in fixing the issue when started from within the Memeory Profiler?

So, to answer your questions,

Yes,

Yes,

Yes,

No.

:-)

===Update===

It only worked the first time.

After that every subsequent attempt to attach to a process crashes the program being profiled about 2 seconds after the memory snapshot is initiated. Could it be related that the fact that the program is sleeping at this point? There's a 10 second Thread.Sleep() so I have time to take a valid snapshot under known conditions. I tried using a Console.Read() for the same purpose but I get the same failure.

I'll try a reboot.

SamNabialek

I was mistaken! Even after a reboot it makes no difference. Our software uses a COM object to display progress information. I can take a snapshot at any point until that COM connection is created. Once that inter-process connection is in place, any attempt at a snapshot kills the process that sends the messages (the process being profiled).

Ideally, I'd like to remove the COM object and log messages in a different manner, but that isn't likely to be sanctioned any time soon.

Jessica R

Hi @SamNabialek

Thanks for those details! Would it be possible for you to share your application with us to investigate? I can send you the details privately on how you can share this with us.

SamNabialek

Hi, Jessica,

Unfortunately, not. The application, the COM object and the data required to run the application against are considered sensitive. Plus my trial period has now expired.

Jessica R

Hi Sam,

Ah I see, would you be able to maybe create a cut down version which doesn't contain any sensitive info but reproduces the crash? We're happy to provide a trial extension!

SamNabialek

HI, Jessica,

Not at this point. I have other higher priorities at the moment. As we're planning to buy licences anyway, I'm sure we'll be able to revisit the issue at some point in the near future.

Thanks for your help anyway,

Jessica R

No worries @SamNabialek and so sorry we weren't able to figure this out! Please let us know when you have a chance to return to this and we'll be happy to continue looking into possible causes.