Hi Yan,
Thanks for the very detailed explanations, not sure we could have got
there ourselves without the support seeing how advanced the
troubleshooting was.
I've opened an issue to get this bug more "official" and tracked in our
official BTS.
That will be included in PacketFence 8.0, and I'll be backporting this
in the maintenance patches of all 7.x versions
Cheers!
--
Julien Semaan
[email protected] :: +1 (866) 353-6153 *155 ::www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
On 2018-03-22 02:50 AM, Yan wrote:
Hi Julien,
First of all thank you very much for your fix. Our developer also fix
the dump script in the same way as you provided but your reply makes
us feel more relieved.
About the root cause of this issue, it's detected by Microsoft
support. And I asked him to offer the method and relative documents as
below.
Just FYI. Thank you.
About the method to trace the issue, refer to below steps:
1.Configure WER in Lsass.exe process, dump the crash info when the
crash happened.
Reg Add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" /f
Reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" /V DumpFolder /t REG_SZ /D "*C:\CrashDumps*" /f
MD*C:\CrashDumps*
Reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" /V DumpType /t REG_DWORD /D 2 /f
Reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" /V DumpCount /t REG_DWORD /D 10 /f
2.After you have the dump file, check the dump stack. You can use
"Windbg" or Microsoft public tool "Public Symbol".
Windbg:https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
Symbol:https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/microsoft-public-symbols
3.If you find your issue stack is similar with below attached, then it
might be the same issue.
0:060> kc
# Call Site
00 ntdll!ZwWaitForMultipleObjects
01 KERNELBASE!WaitForMultipleObjectsEx
02 KERNELBASE!WaitForMultipleObjects
03 kernel32!WerpReportFaultInternal
04 kernel32!WerpReportFault
05 KERNELBASE!UnhandledExceptionFilter
06 ntdll!TppExceptionFilter
07 ntdll!TppWorkerpInnerExceptionFilter
08 ntdll!TppWorkerThread$filt$5
09 ntdll!__C_specific_handler
0a ntdll!__GSHandlerCheck_SEH
0b ntdll!RtlpExecuteHandlerForException
0c ntdll!RtlDispatchException
0d ntdll!KiUserExceptionDispatch
0e ntdsai!draXlateNativeReplyToOutboundReply
0f ntdsai!IDL_DRSGetNCChanges
10 rpcrt4!Invoke
11 rpcrt4!NdrStubCall2
12 rpcrt4!NdrServerCall2
13 rpcrt4!DispatchToStubInCNoAvrf
14 rpcrt4!RPC_INTERFACE::DispatchToStubWorker
15 rpcrt4!RPC_INTERFACE::DispatchToStub
16 rpcrt4!OSF_SCALL::DispatchHelper
17 rpcrt4!OSF_SCALL::DispatchRPCCall
18 rpcrt4!OSF_SCALL::ProcessReceivedPDU
19 rpcrt4!OSF_SCALL::BeginRpcCall
1a rpcrt4!OSF_SCONNECTION::ProcessReceiveComplete
1b rpcrt4!ProcessConnectionServerReceivedEvent
1c rpcrt4!DispatchIOHelper
1d rpcrt4!CO_ConnectionThreadPoolCallback
1e KERNELBASE!BasepTpIoCallback
1f ntdll!TppIopExecuteCallback
20 ntdll!TppWorkerThread
21 kernel32!BaseThreadInitThunk
22 ntdll!RtlUserThreadStart
As for more specific reason, you might have to analysis the source
code to trace.This issue only happens in some specific conditions.
Normally if the replication request is from pure windows(and after
win2000), it won't cause this crash issue.
Finally we don't have any public documents talking about this issue,
but I find some documents related to DRSGetNCChanges.
4.1.10 IDL_DRSGetNCChanges (Opnum 3)
https://msdn.microsoft.com/en-us/library/dd207691.aspx
5.39 DRS_EXTENSIONS_INT
https://msdn.microsoft.com/en-us/library/cc228475.aspx
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
