Runtime: AccessViolationException from Process.GetProcessByName

Created on 12 Mar 2019  ·  4Comments  ·  Source: dotnet/runtime

I don't have a repro yet, but I had the solution open in VS and then tried to do a cmd line operation.

PS> dotnet restore
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.Buffer.Memmove(Byte*, Byte*, UInt64)
   at System.String.Ctor(Char*, Int32, Int32)
   at System.Runtime.InteropServices.Marshal.PtrToStringUni(IntPtr, Int32)
   at System.Diagnostics.NtProcessInfoHelper.GetProcessInfos(System.ReadOnlySpan`1<Byte>, System.Predicate`1<Int32>)
   at System.Diagnostics.NtProcessInfoHelper.GetProcessInfos(System.Predicate`1<Int32>)
   at System.Diagnostics.ProcessManager.GetProcessInfos(System.String)
   at System.Diagnostics.Process.GetProcesses(System.String)
   at System.Diagnostics.Process.GetProcessesByName(System.String, System.String)
   at System.Diagnostics.Process.GetProcessesByName(System.String)
   at Microsoft.Build.BackEnd.NodeProviderOutOfProcBase.GetPossibleRunningNodes(System.String)
   at Microsoft.Build.BackEnd.NodeProviderOutOfProcBase.GetNode(System.String, System.String, Int32, Microsoft.Build.BackEnd.INodePacketFactory, Int64, Int64, NodeContextTerminateDelegate)
   at Microsoft.Build.BackEnd.NodeProviderOutOfProc.CreateNode(Int32, Microsoft.Build.BackEnd.INodePacketFactory, Microsoft.Build.BackEnd.NodeConfiguration)
   at Microsoft.Build.BackEnd.NodeManager.AttemptCreateNode(Microsoft.Build.BackEnd.INodeProvider, Microsoft.Build.BackEnd.NodeConfiguration)
   at Microsoft.Build.BackEnd.NodeManager.CreateNode(Microsoft.Build.BackEnd.NodeConfiguration, Microsoft.Build.Execution.NodeAffinity)
   at Microsoft.Build.Execution.BuildManager.PerformSchedulingActions(System.Collections.Generic.IEnumerable`1<Microsoft.Build.BackEnd.ScheduleResponse>)
   at Microsoft.Build.Execution.BuildManager.HandleNewRequest(Int32, Microsoft.Build.BackEnd.BuildRequestBlocker)
   at Microsoft.Build.Execution.BuildManager.ProcessPacket(Int32, Microsoft.Build.BackEnd.INodePacket)
   at Microsoft.Build.Execution.BuildManager+<>c__DisplayClass68_0.<Microsoft.Build.BackEnd.INodePacketHandler.PacketReceived>b__0()
   at Microsoft.Build.Execution.BuildManager.ProcessWorkQueue(System.Action)
   at Microsoft.Build.Execution.BuildManager.<BeginBuild>b__53_2(System.Action)
   at System.Threading.Tasks.Dataflow.ActionBlock`1[[System.__Canon, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ProcessMessage(System.Action`1<System.__Canon>, System.Collections.Generic.KeyValuePair`2<System.__Canon,Int64>)
   at System.Threading.Tasks.Dataflow.ActionBlock`1+<>c__DisplayClass6_0[[System.__Canon, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].<.ctor>b__0(System.Collections.Generic.KeyValuePair`2<System.__Canon,Int64>)
   at System.Threading.Tasks.Dataflow.Internal.TargetCore`1[[System.__Canon, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ProcessMessagesLoopCore()
   at System.Threading.Tasks.Dataflow.Internal.TargetCore`1+<>c[[System.__Canon, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].<ProcessAsyncIfNecessary_Slow>b__34_0(System.Object)
   at System.Threading.Tasks.Task.InnerInvoke()
   at System.Threading.Tasks.Task+<>c.<.cctor>b__274_0(System.Object)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef, System.Threading.Thread)
   at System.Threading.Tasks.Task.ExecuteEntryUnsafe(System.Threading.Thread)
   at System.Threading.Tasks.Task.ExecuteFromThreadPool(System.Threading.Thread)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

   -1073741819    master ~2    C:\dev\RssBandit\source
PS>

PS> dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview4-010714
 Commit:    a6e7e57e32

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18353
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100-preview4-010714\

Host (useful for support):
  Version: 3.0.0-preview4-27511-06
  Commit:  e9cb907611

.NET Core SDKs installed:
  2.1.600 [C:\Program Files\dotnet\sdk]
  2.1.601 [C:\Program Files\dotnet\sdk]
  2.2.200 [C:\Program Files\dotnet\sdk]
  3.0.100-preview4-010714 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview4-19161-03 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview4-27511-06 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview4-27508-60 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
bug

Most helpful comment

@nguerrera I agree with your analysis. Submitted PR with the fix.

All 4 comments

I assume this was dotnet.exe, not devenv.exe (I believe build runs in both).

We should look carefully at the interop code here, but it could be a bug elsewhere.

edit: I see it was dotnet restore. That reduces the chance it was a native code/interop bug elsewhere.

I think this might have come from https://github.com/dotnet/corefx/commit/d1cdb1b324ea6b52d2b4026bdcc7c2ee1e00b63c#diff-195154b0a603f7e317eeba117b996f8aR303

I might be reading wrong, but it appears that previously the buffer would have remained pinned while we extracted data out of it, but is now passed along as a span over managed memory that can move.

And it looks like there are pointers inside the data that would be invalidated if that happened?

https://github.com/dotnet/corefx/blob/ef145001b10660be940aeb9318e0ff7e306f65bc/src/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.Win32.cs#L354
https://github.com/dotnet/corefx/blob/ef145001b10660be940aeb9318e0ff7e306f65bc/src/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.Win32.cs#L394
https://github.com/dotnet/corefx/blob/ef145001b10660be940aeb9318e0ff7e306f65bc/src/Common/src/Interop/Windows/Interop.UNICODE_STRING.cs#L24

cc @jkotas

@nguerrera I agree with your analysis. Submitted PR with the fix.

Thank you @nguerrera !

Was this page helpful?
0 / 5 - 0 ratings

Related issues

btecu picture btecu  ·  3Comments

aggieben picture aggieben  ·  3Comments

chunseoklee picture chunseoklee  ·  3Comments

omajid picture omajid  ·  3Comments

omariom picture omariom  ·  3Comments