For some time LDP.exe just crash for me on my Windows 11 laptop, I can connect and bind successfully, but as soon as I want to view an object or tree, ldp.exe just crash.
So I decided to capture and analyze the crash dump
So what is going on here? The function takes the following parameters: BerEncode(CtrlInfo *ci, PBERVAL pBerVal)
This lead me to check my controls loaded in ldp.exe – what is that?
Something I’ve never entered at least, that is for sure? But how did it end up there?
It turned out that if, “HKEY_CURRENT_USER\Software\Microsoft\Ldp\Controls\ControlCount” get’s out of sync and contains a value that’s above the numbers of controls saved, it adds this kind of garbage data and will cause ldp.exe to crash!
I tried to dump a NTDS.dit from a RODC with ESEDump – something I haven’t done in years and just stumbled up on the fact that i got NDNC’s (None-Domain Naming Contexts) appearing twice in ‘msDS-HasInstantiatedNCs’ – ESEDump did work as expected but I started to question my self if my code walking the range in the “link_table” worked correctly.
I then thought that this must have something to do with the fact that this RODC is promoted from IFM. Let’s have a look on that attribute with repadmin.exe
Yep, I but those are my two ‘duplicated’ NDNCs – but why? I wrote two articles in the past about how IFM is working and did almost cover this but missed it in the first part as it solidly was focusing on Windows Server 2003 – it says:
Sourcing NDNCs with Windows Server 2003 is only supported by Windows Server 2003 SP1 or later under the following conditions:
Both the DC your souring the IFM from must be running at least Windows Server 2003 SP1 or later and as well the machine intending to become a DC using the source IFM.
The forest functional level (FFL) has to be: Windows Server 2003 (Pre-Windows Server 2003 FFL adding replicas to NCs has to be done on the Domain Naming Master – FSMO) Note: The promotion completes with the sourced IFM even if the forest functional level (FFL) is less than Windows Server 2003 but NDNCs aren’t sourced from the IFM and the following will happen:
The DomainDNSZones and ForestDNSZones are begin replicated in again over the wire using normal replication, as the promoted DC (Sourced from IFM) hosts the DNS Service
I forgot to mention that it’s not supported to keep any NDNCs in the DIT for the Red-Only Domain Controller IFM case – those get wacked and replicated back in again.
The solution here if I really only want to get PRESENT links would be to change incides over the “link_table” to the “present” ones depending on fwd o back links, the Recycle-Bin was not enabled in this environment.
All DIT’s on Windows Server 2025 isn’t 32k page size (Yes I know – I did say that in my last blog post), there is two exceptions, 1: the IPU case aka In-place-upgrade of a pre-Windows Server 2025 DC, in that case the DB will remain as-is in terms of page size.
You can verify the actual page size using a new attribute msDS-JetDBPageSize to determine the page size of a Windows Server 2025 DSA.
This clearly show us that the page size of the one and only DSA running Windows Server 2025 is 8k – this is because the DIT comes from a an IPU’ed aka in-place-upgraded Windows Server 2022 DC.
Let’s have a look with esentutil /m C:\Windows\NTDS\NTDS.dit
For sure the DIT is 8k page size, we can also validate by it’s DB Signature that it was created back in 2017, we can compare with the Distribution DIT that is 32k page size and created in 2023 – more on the Distribution DIT can be found here.
So how do we get to 32k page size on this DC? The answer is you can’t unless you demote and re-promote it. You can get to Windows Server 2025 DFL and FFL – but you can’t enable the “Database 32k pages feature”
There is is a 2:nd way to get up additional DCs running Windows Server 2025 with 8k page size DIT’s.
If you produce IFM media of a Windows Server 2025 DC with 8k page size – the Windows Server 2025 DCs you promote using that IFM media also going to have 8k page size of their DITs.
IPU-DC-02 is promoted using a IFM produced off IPU-DC-01 that once was IPU:ed (In-place-upgraded) from Windows Server 2022.
Extensible Storage Engine – ESENT and the Engine Format Version
Some where after Windows 19H1 version 1903 – released in May 2019 and within Windows 20H1 version 2004 – ESENT seem to have got support for something called “EngineFormatVersion” that enables specific features depending on the ESE Engine version – by default if a ESE DB is attached on a more recent engine than the ESE DB was initially created on, it and it’s logs are upgraded to the current ESE Engine version, that might break backwards compatibility to be able to attach the ESE DB by a older version of the ESE Engine (older version of the operating system with an ESE Engine only supporting certain EngineFormatVersions) – this is by default aka:
ESENT.h
#defineJET_efvUseEngineDefault (0x40000001) // Instructs the engine to use the maximal default supported Engine Format Version. (default)
How ever the Active Directory DSA (ntdsai.dll) have decided to support databases (DIT’s) that don’t even support the efv (Engine Format Version) by setting a hard version of:
ESENT.h
#defineJET_efvWindows19H1Rtm8920 // Last pre-efv version, shipped in Windows 10 until 19H1 release.
This sort of came up and got awareness to the outside world by Michael Grafnetter when someone used his incredible tool dsinternals to attach to a DIT and the default – JET_efvUseEngineDefault was used, it upgraded the DIT and when the Active Directory DSA (ntsdsai.dll) would try to attach to it again it would have a efv (Engine Format Version) that was way head of it’s hardcoded JET_efvWindows19H1Rtm
Ops the DIT can no longer be used by the Active Directory DSA (ntsdsai.dll).
ESENT error -623 is JET_errEngineFormatVersionSpecifiedTooLowForDatabaseVersion
This was resolved by setting the JetSetSystemParameter JET_paramEngineFormatVersion to JET_efvUsePersistedFormat before attaching the database – Michael figured out that this was how the esentutil would do it. DsIntetrnals got updated and I updated my ESEDump tool pretty much the same way:
ESEDump source
if (DbInfoMisc.dwBuildNumber>=20348) err =E.Check(EseHelper.JetSetSystemParameter(ref instance,EseHelper.JET_sesidNil,newIntPtr(EseHelper.JET_paramEngineFormatVersion),newIntPtr(EseHelper.JET_efvUsePersistedFormat),null));
What happened to NTDSUTIL.exe and 8k size DITs?
For some reason if you’re using ntdsutil.exe against a 8k size DIT on Windows Server 2025 and it attaches your DIT – It’s going to destroy your dit and your DC will never boot again – guess what? It upgrades your DB beyond efv (Engine Fromat Version) 8920 (JET_efvWindows19H1Rtm) – This is NOT good and is another bug in Windows Server 2025.
If you’re on Windows Server 2025 with 8k page size DITs – stay away from ntdsutil.exe and especially the file context, it will destroy your DIT. Or to be honest stay away from 8k page size DITs on Windows Server 2025 to being with.
Update 2025-11-07: Microsoft responded quickly and seriously to this issue and a fix is already on it’s way, also note that the DIT is not corrupted in anyway so that data is NOT lost, it’s just upgraded to a later version and the DSA is refusing to attach the DIT as Active Directory don’t support that ESE evf (Engine Fromat Version)
