0

Debugging on a Windows Server 2016 Standard version 1607. Launched a process from windbg 10.0.19041.685 and set the below gflags:

0:038> !gflag 0x020011f0
New NtGlobalFlag contents: 0x020011f0
    htc - Enable heap tail checking
    hfc - Enable heap free checking
    hpc - Enable heap parameter checking
    hvc - Enable heap validation on call
    vrf - Enable application verifier
    ust - Create user mode stack trace database
    hpa - Place heap allocations at ends of pages

Consistently get the below access violation on continue:

(140c.7ec): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!RtlDebugCreateHeap+0x2bb:
00007ff8`f96da01b 66898730010000  mov     word ptr [rdi+130h],ax ds:000001d5`dced0130=eeee

This happens while in a loadlibrary call. Is there a known issue with this gflag setting? Any thoughts?

devstability
  • 29
  • 6
  • As the diagnostics indicate, this is a *"first chance"* exception and *"This exception may be expected and handled."* Is this actually followed up by a second chance exception? – IInspectable Mar 03 '21 at 11:40
  • *rdi* here is pointer to heap (*rdi=RtlCreateHeap*) and this line [`Heap->AllocatorBackTraceIndex = (USHORT)RtlLogStackBackTrace()`](https://github.com/ZoloZiak/WinNT4/blob/master/private/ntos/rtl/heapdbg.c#L275) - error inside call `Heap = RtlCreateHeap` just before this line – RbMm Mar 03 '21 at 12:15
  • If there is no second chance exception you can safely ignore it if this is annoying and you want automatic pass look at debug-> events or sxe documentation. – blabb Mar 03 '21 at 13:38
  • 1
    blabb - *if there..* are not obvious that here is fatal, unhanded exception ? – RbMm Mar 03 '21 at 14:56
  • @Rbmm First chance doesn't necessarily mean fatal – blabb Mar 05 '21 at 02:56
  • @blabb - of course. but here is unhandled exception, visible that in this place - https://github.com/ZoloZiak/WinNT4/blob/master/private/ntos/rtl/heapdbg.c#L275 – RbMm Mar 05 '21 at 07:37
  • this is not software exception, raised by [Rtl]RaiseException, but hardware access violation (look like try write to read only memory). some time this exceptions can be part of program logic, but in most case this kind of exception say that was error in application, even if exception handled. from context visible that this exception (even if handled) say about error. but `!gflag 0x020011f0` - when you modify *NtGlobalFlag* ? look like too late (in *LdrpDoDebuggerBreak*) as result `AVrfInitializeVerifier` not called, but you set *FLG_APPLICATION_VERIFIER*. – RbMm Mar 05 '21 at 09:34
  • you need modify *PEB::NtGlobalFlag* **early** - the best just on first instruction in user mode or not late than before call *LdrpInitializeExecutionOptions* – RbMm Mar 05 '21 at 09:35

0 Answers0