PS v3: some crashing scenarios (ObjectDisposedException) are undebuggable and make PS look unstable by johndog

Active

Type:	Bug
ID:	769351
Opened:	10/31/2012 12:17:59 PM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

If an ObjectDisposedException occurs, it is completely undebuggable, psh just triggers a WER event ("powershell has stopped working") and exits. The end result: it looks like powershell is unstable and at fault.

IF you have a native/managed debugger attached, you can see this mysterious callstack:

>    KernelBase.dll!_RaiseException@16() + 0x54 bytes
    clr.dll!RaiseTheExceptionInternalOnly() + 0x172 bytes
    clr.dll!IL_Throw() + 0xe3 bytes
    System.Management.Automation.ni.dll!513e2557()
    [Frames below may be incorrect and/or missing, no symbols loaded for System.Management.Automation.ni.dll]
    System.Management.Automation.ni.dll!505b9d46()
    System.Management.Automation.ni.dll!505b9530()
    System.Management.Automation.ni.dll!50b4c68e()
    System.Management.Automation.ni.dll!50dfa51c()
    System.Management.Automation.ni.dll!50c1f461()
    System.Core.ni.dll!54642156()
    System.Core.ni.dll!546368c4()
    System.Management.Automation.ni.dll!50c1f677()
    System.Management.Automation.ni.dll!50dd313d()
    System.Management.Automation.ni.dll!50b4fd2a()
    System.Management.Automation.ni.dll!50b7c3a4()
    System.Management.Automation.ni.dll!50b7c20d()
    System.Management.Automation.ni.dll!50b7bf92()
    System.Management.Automation.ni.dll!505a622e()
    System.Management.Automation.ni.dll!505a61ec()
    System.Management.Automation.ni.dll!50b79f58()
    System.Management.Automation.ni.dll!50b51e6b()
    System.Management.Automation.ni.dll!50b516e4()
    System.Management.Automation.ni.dll!50e28f13()
    System.Management.Automation.ni.dll!50ca904c()
    System.Management.Automation.ni.dll!50ca904c()
    System.Management.Automation.ni.dll!505aa2c6()
    System.Management.Automation.ni.dll!505a8546()
    System.Management.Automation.ni.dll!50ba1592()
    System.Management.Automation.ni.dll!505a7f85()
    System.Management.Automation.ni.dll!50b51826()
    System.Management.Automation.ni.dll!50e28f13()
    System.Management.Automation.ni.dll!50e28f13()
    System.Management.Automation.ni.dll!50c11f85()
    System.Management.Automation.ni.dll!50bd8373()
    System.Management.Automation.ni.dll!50ca8dbd()
    System.Management.Automation.ni.dll!50ca904c()
    System.Management.Automation.ni.dll!505a7f85()
    System.Management.Automation.ni.dll!505a56f5()
    System.Management.Automation.ni.dll!505a5043()
    System.Management.Automation.ni.dll!50d49ee8()
    mscorlib.ni.dll!54dfb00b()
    mscorlib.ni.dll!54d84d85()
    clr.dll!_CallDescrWorker@20() + 0x33 bytes
    clr.dll!_CallDescrWorkerWithHandler@24() + 0x8a bytes
    clr.dll!MethodDesc::CallDescr() + 0x148 bytes
    clr.dll!MethodDesc::CallTargetWorker() + 0x21 bytes
    clr.dll!MethodDescCallSite::Call_RetArgSlot() + 0x1c bytes
    clr.dll!ExecuteCodeWithGuaranteedCleanupHelper() + 0xbb bytes
    clr.dll!ReflectionInvocation::ExecuteCodeWithGuaranteedCleanup() + 0xff bytes
    mscorlib.ni.dll!54d84c8a()
    mscorlib.ni.dll!54d87f92()
    mscorlib.ni.dll!54d87f04()
    mscorlib.ni.dll!54dfaf98()
    clr.dll!_CallDescrWorker@20() + 0x33 bytes
    clr.dll!_CallDescrWorkerWithHandler@24() + 0x8a bytes
    clr.dll!MethodDesc::CallDescr() + 0x148 bytes
    clr.dll!MethodDesc::CallTargetWorker() + 0x21 bytes
    clr.dll!ThreadNative::KickOffThread_Worker() + 0x129 bytes
    clr.dll!Thread::DoExtraWorkForFinalizer() + 0xd89e3 bytes
    clr.dll!Thread::ShouldChangeAbortToUnload() - 0x5f6 bytes
    clr.dll!Thread::ShouldChangeAbortToUnload() - 0x53b bytes
    clr.dll!Thread::ShouldChangeAbortToUnload() - 0x4a3 bytes
    clr.dll!ManagedThreadBase::KickOff() + 0x15 bytes
    clr.dll!ThreadNative::KickOffThread() + 0xaf bytes
    clr.dll!Thread::intermediateThreadProc() + 0x48 bytes
    kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
    ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
    ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes

And maybe a couple more exceptions, but then the WER message and the process exits.

Details (expand)

Always Happens

I don't know if this issue existed previously

Run the following script:

function test-disposed()
{
    $event = New-Object Threading.AutoResetEvent true
    $event.Dispose()
    $sb = {
        $event.Set()
    }
    [Threading.ThreadPool]::QueueUserWorkItem($sb)
}

test-disposed
sleep 5000

Result: non-actionable behavior from powershell, making it look likt powershell's fault.

If the equivalent C# code is executed, the runtime will clearly issue an ObjectDisposedException. Powershell should make sure this same exception is either passed through or generated and presented to the user so that they know it's their code and not PS that's at fault, and so they know what to do about it.

0 attachments

Microsoft