1 <?xml version="1.0" encoding="UTF-8" ?>
3 ************************************************
4 PLEASE KEEP MDAS IN ALPHABETICAL ORDER!
5 ************************************************
11 Please add yourself to clrmda discussion alias (just paste this link into
12 IE: http://autogroup/JoinGroup.asp?GroupAlias=clrmda). Once you join,
13 please send out a "Hello World" mail letting us know what problem your
14 trying to solve with MDAs. We're interested in feedback on activation,
15 reporting, VS integration, new MDA requests etc. We'll also send out mail
16 for any breaking changes or new MDAs.
19 Managed Debugging Assistants (MDAs) are switches shipped in the retail
20 runtime to help debug managed code. Each MDA and the problem it addresses
23 ACTIVATION\REPORTING QUICK START:
24 Decide which MDAs you'd like enabled by reading their documentation below and then
25 set the environment variable COMPLUS_MDA equal to a semi-colen delemited list of
26 the names of the MDAs you want enabled. The list is not case sensitive. So, for
27 instance if you want the memberInfoCacheCreation, gcUnmanagedToManaged and
28 gcManagedToUnmanaged MDAs enabled
30 set complus_mda=mEmBeRInFoCacheCreation;gcUnmanagedToManaged;gcManagedToUnmanaged
32 Any managed program run from that command shell will now have these MDAs enabled. If
33 an MDA fires and no debugger is attached then the dialog very much like the dialog you
34 would get if an unhandled exception occurred which will tell you what MDA fired and
35 give you a chance to attach a debugger so you can get a stack trace indicating where
38 If you launch under a debugger you'll have to ensure that the debugger won't ignore the MDAs
39 you enabled. You can force VS to report all MDAs by checking the "Managed Debugging Assistants"
40 box in the exceptions dialog. VS uses the same dialog exceptions use to report MDA messages.
41 Cordbg and windbg report all MDAs by default by splashing the message to the console.
43 ACTIVATION\REPORTING SCENARIOS:
44 The MDA activation and reporting featurs support a variety of scenarios. Those scenarios
45 and the supporting features are described below.
51 Constrained Execution Region (CER) MDA
55 - IllegalPrepareConstrainedRegion
57 These all fire during the analysis of CER call graphs. This analysis
58 can occur for a number of reasons:
60 Early bound; triggered by jitting or ngen'ing a method containing a
61 RuntimeHelpers.PrepareConstrainedRegions() call. Call graph is
62 rooted at the catch/finally/filter/fault blocks belonging to the
63 exception handler the PCR call is associated with.
65 At instantiation of "critical" objects. Instances derived from
66 CriticalFinalizerObject prepare a CER rooted at the finalizer method.
67 Instances derived from SafeHandle or CriticalHandle additionally have
68 the ReleaseHandle(), Dispose() and IsInvalid property getter methods
69 prepared as CER roots.
71 Explicitly via RuntimeHelpers.PrepareMethod() or PrepareDelegates() calls
72 (the CER root method is passed as an argument, indirectly in the case of
73 PrepareDelegate() and possibly with exact generic instantiation information
76 Note that for the early bound (PCR precipitated) case the jit time semantics
77 imply the probe will fire some time before the method which contains the CER
78 root is called (typically just prior to the first call to that method). Since
79 the entire CER call graph is scanned in one go, probes relating to methods
80 deep within the CER will be reported at that time as well (putting the report
81 even further away from the execution). The probes will not fire each time the
82 method is executed (and if the image is ngen'd then they will not fire at runtime at all).
84 Even in the late bound cases a given probe will fire at most once (we remember
85 which CERs we've prepared already, subsequent prepare operations on the same
86 graphs are no-ops). Note that CER graphs that are qualified by generic type
87 parameters (i.e. those CERs whose root method has generic method or class
88 type variables) are considered to define distinct CERs for each possible
89 instantiation of that root method. Therefore multiple calls to PrepareMethod()
90 with such a root method and different instantiations will cause the analysis
91 to be run multiple times and therefore any probes will fire on each invocation
92 (provided the instantiation given hasn't been prepared for that method before).
93 This last case (multiple CER preparations from the same root differing only by
94 generic instantiation) will occur at jit time only for generic instantiations
95 that contain only non-reference types (we jit a separate copy of the code for
96 each of those instantiations). We will refuse to jit-time prepare any method
97 with a generic instantiation containing one or more reference types, since
98 code for those cases is shared (and thus at jit time we cannot predict which
99 exact instantiations will be required at runtime). See the description of
100 the openGenericCERCall probe.
108 AsynchronousThreadAbort (weiwenli)
111 Causes the runtime to fire a MDA message when someone attempts to abort another thread.
117 <asynchronousThreadAbort enable="false" />
121 BindingFailure (t-daveh)
124 This probe fires when an Assembly fails to load.
127 This probe is intended for use in debugging Assembly binding failures. In addition to general information
128 identifying the failure and Assembly, the binding context the Assembly would have been loaded in is included.
129 See http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx for more information.
131 BEHAVIORAL IMPACT: None.
133 OUTPUT: An MDA message is output for each Assembly that fails to load. It includes the failing HRESULT as well
134 as the display name, code base, binding context index, and AppDomain ID that the Assembly would have had.
136 <bindingFailure enable="false" />
140 CallbackOnCollectedDelegate (chriseck)
142 DESCRIPTION: Detects when unmanaged code is trying to call back into the runtime via a delegate which
143 has been garbage collected. Will store up to listSize number of delegates after the GC has released them.
144 The default listSize is 1000 members. The minimum is 50 members. The maximum is 2000.
149 User code AVs when trying to call back into the runtime on a function pointer which was marshaled from
150 a managed delegate. The failure is non-deterministic; sometimes the call on the function
151 pointer succeeds and sometimes it fails.
154 The delegate which from which the function pointer was created and exposed to unmanaged code was collected
155 so when the unmanaged component tries to call on the function pointer it AVs. By enabling this assistant the runtime
156 will not collect "all" of the delegate - instead it leaks just enough of the delegate so that if someone
157 tries to call back on it the MDA will fire.
159 <callbackOnCollectedDelegate listSize="1000" enable="false" />
162 ContextSwitchDeadlock (chriseck)
165 Causes the runtime to fire a MDA message when a deadlock is detected during an attempted context transition
173 A native context transition appears to be deadlocked.
176 Most likely cause is a non-pumping STA thread.
179 An XML message specifying the violation.
181 <contextSwitchDeadlock enable="false" />
184 DangerousThreadingAPI (weiwenli)
187 Causes the runtime to fire a MDA message when someone attempts to call dangerous threading API.
193 <dangerousThreadingAPI enable="false" />
197 DirtyCastAndCallOnInterface (chriseck)
200 A native component makes a call on an IUnknown or IDispatch interface without first QI-ing for the correct interface.
208 AVs or unexpected memory corruption when making a call from native code into the CLR on a CCW.
211 Caller neglected to QI for the correct interface.
214 An XML message specifying the violation.
216 <dirtyCastAndCallOnInterface enable="false" />
219 DisconnectedContext (chriseck)
222 The CLR attempts to transition into a dead context while trying to service a request concerning a
223 COM object living in that dead context. This can happen while cleaning up RCWs or servicing QIs.
231 Calls on RCWs living in dead contexts are not serviced, or cleanup of COM interface pointers occurs in
232 a context other than the one in which the interface pointers live.
235 The OLE context is disconnected.
238 An XML message specifying the violation.
240 <disconnectedContext enable="false" />
244 DllMainReturnsFalse (slidin)
247 Activated by default under a managed debugger.
249 <dllMainReturnsFalse enable="false" />
252 ExceptionSwallowedOnCallFromCom (dmortens)
255 Causes the runtime to fire a MDA message when an error occurs while determining how to marshal the parameters
256 of a member member to be called from COM.
264 A failure HRESULT is returned to COM without the managed method having been called.
267 This is most likely due to an incompatible MarshalAs attribute on one of the parameters.
270 An XML message specifying the violation.
272 <exceptionSwallowedOnCallFromCom enable="false" />
279 Causes the runtime to fire a MDA message when the runtime calls QueryInterface on a COM interface pointer
280 on behalf of a RCW, and the QueryInterface call fails because the call was attempted in the wrong context or
281 because an OLE owned proxy returned a failure HRESULT.
289 A cast on a RCW fails, or a call to COM from a RCW fails unexpectedly.
292 Calling from the wrong context or the registered proxy is failing the QueryInterface call.
295 An XML message specifying the violation.
297 <failedQI enable="false" />
301 GcManagedToUnmanaged (chrisk)
303 DESCRIPTION: Causes a garbage collection whenever a thread transitions from managed to unmanaged
304 code (also see gcUnmanagedToManaged).
308 SYMPTOM: An unmanaged user component AVs when trying to use a managed object which had been exposed to
309 COM. The COM object appears to have been released. The AV is non-deterministic.
311 CAUSE: If an unmanaged component is not ref counting a managed COM object correctly
312 then the runtime could collect a managed object exposed to COM when the unmanaged component still
313 holds a reference to the object. The runtime calls release during GCs so if the user component uses the
314 object before the GC than it will not yet have been collected which is the source of the non-determinism.
315 Enabling this assistant will reduce the time between when the object is eligible for collection and release
316 is called helping to track down which unmanaged component first tries to access the collected object.
320 <gcManagedToUnmanaged enable="false" />
323 GcUnmanagedToManaged (chrisk)
326 Causes a garbage collection whenever a thread transitions from unmanaged to
327 managed code (also see gcManagedToUnmanaged).
330 This assistant changes the behavior of the runtime. When enabled more GC will occur.
335 An application running unmanaged user components (COM\PInvoke) is showing a non-deterministic AV
339 If an application is running unmanaged user components then those components may have corrupted
340 the GC heap. This will cause the runtime to AV when the GC tries to walk the object graph.
341 Enabling this assistant will reduce the time between when the unmanaged component corrupts the GC
342 heap and when the AV happens by forcing a GC to occur before every managed transition.
347 <gcUnmanagedToManaged enable="false" />
351 IllegalPrepareConstrainedRegion (rudim)
353 This is an error event. The RuntimeHelpers.PrepareConstrainedRegions() method (PCR)
354 call we use to mark exception handlers as introducing CERs in their catch/finally/fault/filter
355 blocks are only valid when used in that context. They must immediately precede the try
356 statement of the exception handler. (This is at the IL level, so it's obviously permissible
357 to have non-code generating source in between the two, such as comments). In the future
358 these markers will be generated by a compiler (from a new, higher level syntax for marking
359 CERs) and the code author won't have to worry about this. But until then we help the author
360 out by generating this MDA when the PCR call appears anywhere else in the code:
362 If this MDA is firing the sort of symptoms you'd expect are probably as if CERs had
363 stopped working (i.e. runtime errors from jitting, thread aborts or generics lazy type
364 loading occurring inside CER regions). This is because they probably intended to declare
365 a CER region but failed by mispositioning the PCR call.
367 <illegalPrepareConstrainedRegion enable="false" />
370 InvalidApartmentStateChange (chriseck)
373 Causes the runtime to fire a MDA message when someone attempts to change the COM apartment state of a thread which
374 has already been COM initialized to a different apartment state.
382 A thread's COM apartment state is not what was requested.
385 The thread was previously initialized to a different COM apartment state.
388 An XML message specifying the violation.
390 <invalidApartmentStateChange enable="false" />
393 InvalidCERCall (rudim)
395 This is an error report. It occurs whenever a location within the CER graph
396 calls a method which has no reliability contract or an excessively weak contract.
397 A weak contract is one which declares that the worst case state corruption is of
398 greater scope than the instance passed to the call (i.e. the appdomain or process
399 state may become corrupted) or that its result is not always deterministically
400 computable when called within a CER. Either of these states indicates that the
401 code called may thwart the efforts of the rest of the CER to maintain consistent
402 state (CERs allow an author to treat errors in a very deterministic manner as a
403 way on maintaining whatever internal invariants are important to the particular
404 application and thus allow it to continue running in the face of transient errors
405 such as out of memory).
407 In terms of reliability contract syntax a weak contract is one that does not specify
408 a Consistency enumeration or specifies ones one of Consistency.MayCorruptProcess or
409 Consistency.MayCorruptAppDomain or that does not specify a CER enumeration or specifies CER.None.
411 When this probe fires there's a chance that the method being called in the CER
412 can fail in a way that the caller didn't expect or that leaves the appdomain or
413 process state corrupted or non-recoverable. Of course the called code may actually
414 work perfectly and the author merely hasn't gotten round to adding a contract. But
415 the issues involved in hardening code in this way are subtle and most "random"
416 code doesn't fall out this way. The contracts serve as markers that the author
417 has done their homework and hardened their algorithms and also as promises that
418 these guarantees will never backslide in future revisions of the code. (I.e.
419 they're declarations of intent rather than mere indicators of implementation).
421 Because any method with a weak or non-existent contract may potentially fail in
422 all sorts of unpredictable manners anyway, the runtime doesn't attempt to remove
423 any of its own unpredictable failures from the method (introduced by lazy jitting
424 or generics dictionary population or thread aborts for instance). That is, when
425 this MDA fires it indicates that the runtime didn't include the called method in
426 the CER being defined; the call graph was pruned at this node (to carry on preparing
427 this sub-tree would just serve to help mask the potential error).
429 So the symptoms this MDA may indicate are unfortunately very broad. They could see
430 an unexpected OutOfMemory or ThreadAbort exception (among others, we don't guarantee
431 the list) at the callsite into the "bad" method because the runtime didn't prepare
432 it ahead of time or protect it from ThreadAbort exceptions at runtime. But worse than
433 that, any exception that comes from this method at runtime could be leaving the
434 appdomain or process in a bad state, which is presumably counter to the wishes of
435 the CER author, since the only reason to declare a CER is to avoid large scale state
436 corruptions such as these in the first place. How corrupt state manifests itself is
437 very application specific (since the definition of consistent state belongs to the
440 <invalidCERCall enable="false" />
443 InvalidFunctionPointerInDelegate (chriseck)
446 An invalid function pointer is passed in to construct a delegate over a native function pointer.
454 AVs or unexpected memory corruption when using a delegate over a function pointer.
457 An invalid function pointer was specified.
460 An XML message specifying the violation.
462 <invalidFunctionPointerInDelegate enable="false" />
466 InvalidIUnknown (chriseck)
469 An invalid IUnknown* is passed to managed code from native code. The IUnknown fails to return success
470 when queried for the IUnknown interface.
478 Unexpected error when marshaling a COM interface pointer during argument marshaling.
481 A misbehaving QueryInterface implemenation on the COM interface passed to the runtime.
484 An XML message specifying the violation.
486 <invalidIUnknown enable="false" />
489 InvalidMemberDeclaration (dmortens)
492 Causes the runtime to fire a MDA message when an error occurs while determining how to marshal the parameters
493 of a member member to be called from COM.
501 A failure HRESULT is returned to COM without the managed method having been called.
504 This is most likely due to an incompatible MarshalAs attribute on one of the parameters.
507 An XML message specifying the violation.
509 <invalidMemberDeclaration enable="false" />
512 InvalidOverlappedToPinvoke (mstanton)
515 This probe fires when an overlapped pointer not created on the gc heap is passed to a popular
516 Win32 function. The potential for heap corruption is high when this is done because the
517 AppDomain where the call is made may unload. In that case, the user code will either free
518 the memory for the overlapped pointer, causing corruption when the operation finishes, or
519 the code will leak the memory, causing difficulties later.
521 Here are the functions that this MDA tracks:
524 HttpApi.dll HttpReceiveHttpRequest
525 IpHlpApi.dll NotifyAddrChange
526 IpHlpApi.dll NotifyRouteChange
527 kernel32.dll ReadFile
528 kernel32.dll ReadFileEx
529 kernel32.dll WriteFile
530 kernel32.dll WriteFileEx
531 kernel32.dll ReadDirectoryChangesW
532 kernel32.dll PostQueuedCompletionStatus
533 MSWSock.dll ConnectEx
537 WS2_32.dll WSARecvFrom
538 MQRT.dll MQReceiveMessage
540 The way to fix this problem is to use a System.Threading.Overlapped object, calling
541 Overlapped.Pack() to get a NativeOverlapped structure that can be passed to the
542 function. If the AppDomain unloads, the CLR will wait until the async operation completes
543 before freeing the pointer.
545 Note that this MDA is by default only fires if the P/Invoke is defined in your
546 code, using your debugger to report the JustMyCode status of each method.
547 A debugger that doesn't understand JustMyCode (such as mdbg with no extensions)
548 will not let this MDA fire. You can activate this MDA using a config file
549 if you explicitly set justMyCode="false" in your .mda.config file.
552 An XML message specifying the overlapped pointer address, the module name, and the win32
553 function that was called.
555 <invalidOverlappedToPinvoke enable="false" justMyCode="true"/>
559 InvalidVariant (chriseck)
562 Causes the runtime to fire a MDA message when an invalid VARIANT structure is encountered.
570 Unexpected behavior during a transition between native and managed code involving the marshaling
571 of an object to a VARIANT or vice versa.
574 The native code is passing a malformed VARIANT structure to the runtime.
577 An XML message specifying the violation.
579 <invalidVariant enable="false" />
583 JitCompilationStart (chrisk)
586 Enabling this assistant causes a message to be generated whenever a method which matches the filter is jitted.
587 This assistant was primarily used to test the MDA framework but could also be used.
590 None. The performance difference should also be negligible as this assistant is only fired when the method is
596 clrjit.dll is loaded in a performance scenario in which all assemblies are ngened.
599 This would likely be a bug in the runtime. Enabling this assistant will help determine which method is
603 Methods which match the filter that are being jitted.
605 <jitCompilationStart enable="false">
606 <methods justMyCode="true">
607 <match break="false" name="MyMethod" />
609 </jitCompilationStart >
615 It is unsafe to execute managed code on a thread that holds the operating system's LoaderLock.
616 Violating this rule can lead to deadlocks or calls into DLLs that have not yet been initialized.
617 Such failures are somewhat random and can appear or disappear from run to run of a process.
618 On some platforms, we can detect whether the current thread holds the LoaderLock during a
619 transition from native to managed code.
622 The extra checks can cause a slight slowdown on calls from native code to managed code. This
623 slowdown is on the order of 10 instructions.
626 <loaderLock enable="false" />
630 LoadFromContext (t-daveh)
633 This probe fires when an Assembly loads in the LoadFrom binding context. This happens on some but not all calls
634 to Assembly.LoadFrom and can also occur when loading dependencies for a separate Assembly loading call.
637 This probe is primarily intended for use in debugging Assembly binding failures, which often occur because a call
638 to Assembly.LoadFrom does not imply that the Assembly will be loaded in the LoadFrom context. Binding contexts
639 affect Assembly behavior, and in almost all cases it is recommended that the LoadFrom context be avoided. See
640 http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx for more information.
642 BEHAVIORAL IMPACT: None.
644 OUTPUT: An MDA message is output for each Assembly loaded in the LoadFrom context. It includes the display name
645 of the Assembly and its code base.
647 <loadFromContext enable="false" />
651 MarshalCleanupError (chriseck)
654 The CLR encounters an error while attempting to clean up temporary structures and memory required for marshaling data types between
655 native / managed code boundaries. It is likely that a memory leak will occur.
663 Memory leak occurs when making native / managed code transitions, runtime state such as thread culture is not restored, or errors occur
664 in SafeHandle cleanup.
667 An unexpected error occurred while cleaning up temporary structures. Review all SafeHandle destructor / finalizer implementations and
668 custom-marshaler implementations for errors.
671 An XML message specifying the encountered problem.
673 <marshalCleanupError enable="false" />
679 This probe fires when reflection creates a MemberInfo cache. This happens on calls to
680 Type.GetMethod, Type.GetProperty, Type.GetField etc. Creation of this cache is expensive in working set
681 because it pages in metadata which is usually stored in a cold section of the PE file and because
682 reflection eagerly caches MemberInfos. The Reflection team has plans in Beta2 to make the cache lazy.
685 This probe is primarily intended for use in a regression test which ensures that "heavy" reflection is
686 not used is an optimized scenario.
688 BEHAVIORAL IMPACT: None.
690 OUTPUT: A MDA message is output for each time a MemberInfoCache is created.
692 <memberInfoCacheCreation enable="false"/>
695 ModuloObjectHashcode (chrisk)
698 Enabling this assistant causes Object.GetHashcode to return the modulus of the hashcode it would
699 have otherwise returned. This does not affect any other implementation of GetHashcode.
707 Varied. Generally, after debugging, it is discovered that an object with the wrong identity
708 is being manipulated.
711 Program is using an objects hashcode to identify the object. While it is true that if two
712 object references are the same their hashcodes are the same, the converse is not true. If two
713 object references have the same hashcodes that does not imply they refer to the same object.
714 Making this assumption will cause incorrect program behavior in the very rare case when it is false.
715 Enabling this assistant will make it much more likely to have "hashcode collisions" and flesh out bugs.
719 <moduloObjectHashcode modulus="1" enable="false" />
722 NonComVisibleBaseClass (dmortens)
724 This error event is fired when a QueryInterface call is made on a CCW requesting the class
725 interface or the default IDispatch, not implemented by an explicit interface, of a COM visible
726 managed class that derives from a non COM visible base class.
728 The symptoms the user will see is the QueryInterface call failing with a
729 COR_E_INVALIDOPERATION HRESULT.
731 <nonComVisibleBaseClass enable="false" />
735 NotMarshalable (chriseck)
738 The CLR encounters a COM interface pointer with no valid proxy/stub registered or a misbehaving IMarshalable implementation while attempting
739 to marshal the interface across contexts.
747 Calls are not serviced, or calls occur in the wrong context for COM interface pointers.
750 The CLR encounters a COM interface pointer with no valid proxy/stub registered or a misbehaving IMarshalable implementation.
753 An XML message specifying the violation.
755 <notMarshalable enable="false" />
758 OpenGenericCERCall (rudim)
760 This event is a warning. It is generated when a CER graph with generic type
761 variables at the root method is being processed at jit/ngen time and at least
762 one of the generic type variables is an object reference type. Since at jit time
763 an instantiation containing an object reference type is only representative (the
764 resultant code is shared such that each of the object reference type variables may
765 in fact be any object reference type) we cannot guarantee prepare all runtime
766 resources ahead of time. In particular methods with generic type variables sometimes
767 lazily allocate resources behind the user's back (these are referred to as generic
768 dictionary entries). For instance the statement "List<T> list = new List<T>();" where
769 T is a generic type variable will need to lookup and possibly create the exact
770 instantiation (e.g. List<Object>, List<String> etc.) at runtime and this might
771 fail for a variety of reasons beyond the author's control (out of memory, for instance).
773 This probe shouldn't fire for any of the non-jit cases (they always provide an
774 exact instantiation to work with).
776 When this probe fires the likely symptoms you might see are that CERs will appear not
777 to work at all for the bad instantiations (in fact we don't even attempt to implement
778 a CER in the circumstances where the event fires). So if the author uses a shared
779 instantiation of the CER they will not avoid runtime injected jit or generics type
780 loading errors or thread aborts within the region of the supposed CER.
782 <openGenericCERCall enable="false" />
785 OverlappedFreeError (mstanton)
788 This probe fires if code calls System.Threading.Overlapped.Free(NativeOverlapped *) before
789 the overlapped operation has completed. The overlapped operation needs to be cancelled
793 An XML message specifying the overlapped pointer address that was freed pre-maturely.
795 <overlappedFreeError enable="false" />
801 Logs a message the first time a PInvoke call is call is made.
804 An XML message specifying the managed PInvoke signature and target which was called for the first time.
806 <pInvokeLog enable="false" />
809 PInvokeStackImbalance (chrisk)
812 Causes the runtime to compare the actual stack depth before and after a PInvoke call against
813 what the call depth should be given the calling conventions specified in the DllImport attribute
814 and the arguments. If the depths do not agree than the MDA will fire. (Future versions of this
815 assistant will also check the stack depth of "reverse-PInvoke" or calling back into managed code via
816 a function pointer representing a managed delegate.)
819 This assistants disables PInvoke marshaling optimizations and so PInvoke calls will be slower.
822 Activated by default under a managed debugger.
827 An application AVs when placing or just after placing a PInvoke call.
830 Very likely that the managed signature, the DllImportAttribute, does not match the unmanaged
831 signature. Either the number or size of the parameters does not match or the calling convention
832 does not match. Try explicitly specifying the calling convention on both the managed and unmanaged
833 sides. It is also possible, though much less likely, that the unmanaged function unbalanced the
834 stack for some other reason such as a bug in the unmanaged compiler.
837 An XML message specifying the managed PInvoke signature which detected the unbalanced stack.
839 <pInvokeStackImbalance enable="false" />
842 RaceOnRCWCleanup (chriseck)
845 Causes the runtime to fire a MDA message when it detects that a RCW is in use while the user attempts
846 to free it via Marshal.ReleaseComObject or other such construct.
854 AVs or memory corruption during or after freeing a RCW via Marshal.ReleaseComObject or other such construct.
857 The RCW is in use on another thread or further up the freeing thread stack. It is illegal to free
858 a RCW that is in use.
861 An XML message specifying the violation.
863 <raceOnRCWCleanup enable="false" />
869 Threads that switch between native and managed code in either direction must perform an
870 orderly transition. However, certain low level extensibility points in the operating system
871 (like the Vectored Exception Handler) allow switches from managed to native code without
872 performing an orderly transition. Any native code that executes inside these extensibility points
873 must avoid calling back into managed code. If this rule is violated, the object heap can become
874 corrupted and other serious errors can occur. This assistant can detect attempts to transition
875 from native to managed code in cases where a prior switch from managed to native code was
876 not performed through an orderly transition.
879 The extra checks can cause a slight slowdown on calls from native code to managed code. This
880 slowdown is on the order of 5 instructions.
883 <reentrancy enable="false" />
887 ReleaseHandleFailed (rudim)
889 This is an error event. It fired when the ReleaseHandle method of a SafeHandle or
890 CriticalHandle subclass returns false. These methods are provided by the author subclassing
891 SafeHandle or CriticalHandle so the circumstances are handle specific, but the contract
894 Safe and critical handles represent wrappers around vital process resources that
895 cannot be permitted to leak (otherwise the process will become unusable over time).
897 Therefore the ReleaseHandle method must not fail to perform its function
898 (once we've acquired such a resource, ReleaseHandle is the only means we have
899 of releasing it, so failure implies resource leakage).
901 Therefore any failure which does occur during ReleaseHandle (and impedes the
902 release of the resource) is a serious bug on the part of the author of the ReleaseHandle
903 method itself (it is their responsibility to make sure the contract is fulfilled, even
904 if they're calling other people's code to achieve the end effect).
906 To aid in debugging such leaks we allow ReleaseHandle to return a boolean result and
907 if that result is false we generate this MDA with some state information that might
908 help track down the problem. (We used to throw an IOException in earlier builds of Whidbey).
910 The symptoms the user might see in situations where this MDA fires is resource
911 leakage (for whatever resource the safe or critical handle is a wrapper for or at
912 least handles against that resource which can be scarce in their own rite).
914 <releaseHandleFailed enable="false" />
918 ReportAvOnComRelease (chriseck)
921 Occasionally an exception is thrown due to user refcount errors while performing COM Interop and
922 using Marshal.Release or Marshal.ReleaseComObject mixed with raw COM calls. Today, this exception
923 is simply discarded, since not doing so would cause an AV in the runtime and bring it down. Using
924 this assistant, such exceptions can be detected and reported instead of simply discarded.
926 Two modes are available " if AllowAV is true, then the assistant simply strips the exception handling
927 from the function. If it is false (by default), then the exception handling occurs, but a warning
928 message is reported to the user to indicate that an exception was handled.
930 <reportAvOnComRelease allowAv="false" enable="false" />
933 VirtualCERCall (rudim)
935 This is just a warning. It indicates that a callsite within a CER call graph
936 refers to a virtual target (i.e. a virtual call to a non-final virtual method
937 or a call via an interface). The runtime cannot predict the destination method
938 of these calls from IL and metadata analysis alone (which is all we have), so
939 we won't descend into that call tree and prepare it as part of the CER graph (or
940 automatically block thread aborts in that subtree either). So this warns of cases
941 where a CER might need to be extended manually via explicit calls to PrepareMethod()
942 (once the additional information required to compute the call target is known at
945 Symptoms of a problem reported via this probe are pretty much the same as above. The
946 callsite can experience a failure from the runtime if the target wasn't explicitly
947 prepared by another means (e.g. PrepareMethod) and it's not defined whether or not
948 the code to be run meets any reliability contracts since the runtime couldn't scan
949 ahead to tell. If the eventual target wasn't hardened for deterministic operation
950 then it could surprise the author of the CER as above.
953 <virtualCERCall enable="false" />
projects / platform / upstream / coreclr.git / blob