Memory Leak Issues with Windows Deployment Services (WDS) and MDT Setup

Question

Memory Leak Issues with Windows Deployment Services (WDS) and MDT Setup

jbrduka 5

There are ongoing issues with a WDS (Windows Deployment Server) and MDT (Microsoft Deployment Toolkit) setup. When attempting PXE booting on devices, most do not progress far enough to initiate the MDT process. Many machines are stuck at the “Getting boot file: boot\x64\wdsmgfw.efi” screen, and during this time, the WDS Service gradually consumes all available RAM, rendering it unusable and requiring a hard reset.

Previously, when this occurred about a month or two ago, uninstalling a Windows Update resolved the issue. Since then, Windows Updates have been disabled, yet the problem has reoccurred.

Currently, the only consistent factor among the affected machines appears to be the BIOS vendor, which is Insyde, while a model with AMI BIOS does not exhibit this issue.

Efforts to find solutions have included adjustments to TFTP, Variable Window Size, and other settings without success. Additionally, switching to a different server installation temporarily resolved the issue before it also exhibited the memory leak problem.

Is anyone else experiencing similar problems?

Server setup: VM on Hyper-V, Windows Server 2022, 16GB RAM, 12 Virtual Cores.

Client setup: Various HP laptops.

Any and all tips would be appreciated!

Josh Zinnel 0 Reputation points

2025-03-17T17:44:16.1633333+00:00

Yes, I'm seeing this same issue but with Dell computers. It will hang on the NBP file before continuing, up to 10 minutes or so. But it doesn't do it all the time or even twice in a row on the same computer. The WDS process can consume up to 4 GB of virtual memory (not necessarily physical mem) extra per PXE booting device. It does eventually release this memory, but when you're imaging dozens of computers, it can max out the virtual memory on the server, making it unstable until it crashes. I'm on Server 2019, VM, 12 GB mem, 4 cores. I've not tried bringing up another distribution point yet but that was going to be my next move.

Edit: So far my investigation has turned up a problem with the TFTP traffic at that stage. Using Wireshark, I have observed one of our Dell models (Optiplex 7010 SFF Plus) using a transfer window size of 4 for that file, and sometimes this flow works perfectly. The server sends 4 packets, the client acknowledges the last one in the sequence. But other times, something gets out of sync, and the client will acknowledge block 400, for example, so the server resends packets 397-400. Then the client acknowledges block 400 again, so the server resends the same four, and this amplifies to where the server and client are talking past each other. The send and receive are almost at the same time, so the server is furiously trying to reply to every client acknowledgement packet, but the client is getting the same repeat blocks back until finally it slowly manages to go up, but it gets to the point where the client is having to repeat itself dozens of times before they make progress. The client might get later packets, but it's acknowledgement of those is delayed because it's backlogged so much trying to reply to the previous packets. I did a capture on an older Dell model (OptiPlex 5070), and it doesn't set a window size at all and uses a size of just 1. For the NBP file, this seems to be the best.
Josh Zinnel 0 Reputation points

2025-04-03T15:54:53.4866667+00:00

I just spun up a new server and I'm getting the same result with the same test variables. On a Dell 7010 SFF Plus, it first uses a TFTP window of 4 to transmit the NBP file. This sometimes breaks down where not all 4 packages get acknowledged but the client and server start talking past each other and duplicating packets. There's not a particular spot in the 750 or so packets where it breaks down but the longer it goes on, the worse it gets. This server is Windows 2022 vs 2019 for the original so the server OS isn't the issue.
link470 0 Reputation points

2025-04-03T22:31:31.9733333+00:00

I'm running into what sounds like the exact same issue. WDS without MDT, ConfigMgr 2409, Windows Server 2019 and 64GB RAM. Before the 2409 upgrade (when I also installed March 2025 Cumulative Updates on the ConfigMgr server), there was no issues imaging.

I'm unsure if this is a problem introduced with new BIOSs on new hardware, or if this is a problem introduced with Windows Updates in the last few months or going from ConfigMgr 2303 to 2409.

Loading the NBP file takes forever now (where it used to take a second or less). No changes have ever been made to WDSs TFTP variables or any other settings. We simply enabled PXE in ConfigMgr and haven't changed it since. I should also note that it's only the download of the NBP file that seems to cause the WDS memory usage to rise; as soon as that file stops downloading, the tech hits ENTER at the workstation, and the .WIM file starts downloading, the memory usage stops rising for the WDS service. But the memory also doesn't seem to be released either, at least not right away that I've seen. I've had to stop the WDS service and start it again for memory usage to go back down. Even just attempting to image 5 machines will spike the service memory from nothing to almost the entire 64GB of the server, causing the VM to crash and restart.

Any updates Josh?
Josh Zinnel 0 Reputation points

2025-04-04T13:28:16.68+00:00

Scott, unfortunately, no. But our ConfigMgr is on version 2403. We are using WDS as part of ConfigMgr with an MDT enabled task sequence (I know, we will have to migrate off that soon). We are planning to upgrade to 2409 soon. I'm having one of our other sites do the same wireshark capture to see if they're seeing the same thing but they've said they're not having any issues. Our problems started sometime between December and January. No changes were done to ConfigMgr during that time, so it's a Windows update or a network change, I figure. Notably, we had no issue with these models before December, or not detectible anyway. I do not see a way to change the TFTP window for the NBP file, but the settings you set in the registry are obeyed for the boot.wim. For the NBP file, it looks like it negotiates, and the NIC tells it to use a window of 4 but no idea how you control that. I didn't see anything remotely close in the BIOS. It still doesn't explain what changed from Dec to Jan though.

Your description matches what I'm seeing, though 5 computers shouldn't consume 64GB of RAM. Our one server was originally 8 and it could support 4 imaging without crashing. Another thing to check is whether you see the same problem with the same computer repeatedly or only some of the time. I found it sometimes doesn't get stuck in an echo chamber but more than likely it will, sometimes sooner sometimes later. There's about 750 blocks that the server sends. I ran some stats by our network team, and there's only a few hops, 6, which they said was the least amount possible (it wasn't going out of our site or anything). And they had me run MTU tool and said nothing there looked wrong. Jumbo packets were allowed (limit ~9800). Ping times were 1 ms or less.
link470 0 Reputation points

2025-04-04T23:10:58.4666667+00:00

Just to add to this, I've had our techs try the same machines we've been having troubles with (Lenovo M70q Gen 3 and Gen 5 models) out at some of our sites with distribution points at them. The DPs are all also Windows Server 2019, same March 2025 cumulative updates as our main ConfigMgr site server, but 8GB RAM each for those DP servers. Each site they've tested so far performs perfectly and the NBP file does its usual 1 second download or so before the tech hits ENTER and the WIM starts downloading. These DPs with 8GB of RAM can easily handle 30 to 60 machines being imaged at once, and previously, the head office would do that as well.

It just seems to be our head office (where the boot/PXE/DP server is the ConfigMgr site server) that's having these issues. Those Gen 3/Gen 5 M70q machines take a good 5 to 15 minutes to download the NBP file, while RAM spikes on the WDS service on the site server. I found that after the imaging of the machine is done, the service does release the memory, so that's good.

We also tried several other machines (Lenovo L series ThinkPads, an older M93p workstation, a Yoga) and all downloaded the NBP file quickly at the head office, even using the exact same network cable/switch port as the M70q machines that took forever, so the issue seems to be something with the M70q machines, and only at the head office, and only since either recent Windows Updates or our ConfigMgr environment upgrade from 2303 to 2409.

EDIT: For the BIOS versions, we've tried the latest BIOS on the Gen 3 machines, and the stock factory BIOS on the Gen 5 machines as well as latest. No difference. Secure Boot is enabled on all client machines.
Josh Zinnel 0 Reputation points

2025-04-07T21:30:09.63+00:00

Yeah, that lines up with what I've discovered in my environment, except different hardware. Also, our DPs are not on the site server but a dedicated server. Now I understand why you had 64 GB of mem. I found that it can help to increase the virtual memory limit, to a point. Oddly, WDS seems to allocate most of that "memory leak" to virtual memory instead of physical memory, so in Resource Monitor, monitor the "Commit" column. I still can't rule out some kind of network or firewall change, but the preliminary discussion I've had with the network team didn't lead to any insights. I'm still waiting to hear from another site if they're seeing the same pattern in packet captures. Afterwards, I'm out of ideas and will ask my supervisor about opening a Microsoft Support Ticket.
link470 0 Reputation points

2025-04-15T22:52:06.11+00:00

I've done a bit more troubleshooting on my side. In addition to the Lenovo ThinkCentre M70q Gen 5, I'm now seeing the same problem on a Lenovo ThinkPad L14 Gen 4. Rarely, they'll PXE boot and load the NBP file nice and quick (usually on a first attempt after not imaging anything for awhile, but this is inconsistent), but most of the time, the NBP file download is slow and the WDS service rises in memory usage.

I think you're onto something with the window size. The M70q Gen 5 has an option in the BIOS to change the TFTP Window Size. By default, it's 4 (it's a dropdown menu with 1, 2, 3, and 4 as options). If I change this to 1 and attempt to PXE boot, PXE booting works every time.

On the L14 Gen 4, the BIOS didn't have this option initially. But after updating the BIOS to the current version, it now shows the same TFTP Window Size option, and again, changing this from its default of 4, down to 1, works every time as well. If I change both the M70q and L14 back to a window size of 4, they both halt at the downloading NBP file part again.

What's driving me nuts is that our networking setup at every site is identical; same layer 3 routers, same switches, same firmware levels across the board, same configuration templates, same ConfigMgr/DP server OS of Server 2019, same March 2025 cumulative updates. Yet, all the sites with only a DP work totally fine, and this is only a problem at the head office where the DP is also the main ConfigMgr site server. Prior to the upgrade from ConfigMgr 2303 to 2409, and updating from December 2024 cumulative updates to March 2025 cumulative updates, this wasn't an issue. The problem only started after this, and only for these newer model machines.

2 more interesting observations:
•During the NBP file download process, if I unplug the network cable from the machine and then plug it right back in, the download process immediately finishes and proceeds to download the boot .wim image.
•If I take the same M70q and L14 and plug them into a switch only 1 switch hop away from the server, they download the NBP file quickly every time, even with a window size of 4. Again, this makes no sense to me given that the other sites are all fine with a device booting over the exact same switches/layer 3 devices that I bypassed in this test.

Any updates on your side Josh? April's cumulative updates are out now but I haven't installed them yet.
Josh Zinnel 0 Reputation points

2025-04-16T00:14:11.72+00:00

No, I'm afraid I haven't made any additional progress on this issue. I work in education so we haven't started reimaging mass numbers of computers yet, and my time has been spent elsewhere. But yeah, this is frustrating for sure. I didn't see a way to change the TFTP window size on Dell hardware, but I think your experience confirms that setting is the key. No idea what caused the problem though. I'm just as baffled. I've seen other comments like the OP's elsewhere going back years but the threads never zeroed in on TFTP so I do think we're ahead of the game at least. It's like WDS doesn't wait long enough for the replies from the client. If it waited just a millisecond longer, it might never get into the packet race condition. I wonder if slowing down the network link would have any positive impact? I don't know much about WDS but it's got to be a rather old system at this point and probably hasn't seen many changes in a long time. If, historically, at this stage, TFTP always negotiated a window size of 1, you wouldn't bother waiting any longer to send the next packet.
link470 0 Reputation points

2025-04-16T05:10:30.47+00:00

Have you ever changed any PXE variables (window size, block size, any WDS settings, etc.)? Our WDS setup is exactly as ConfigMgr sets it up and nothing else WDS wise has been modified. I did try unchecking the Enable Variable Window Extension checkbox on the TFTP tab in WDS Properties and then restarting WDS, but this didn't make a difference for me, so I set it back to checked.

3 things I can think of trying are:
•Uninstalling and reinstalling PXE on the site server (where our problem exists, as none of our sites/DPs are having the problem)
•Testing the ConfigMgr PXE responder instead of WDS
•Testing the April 2025 cumulative updates on the ConfigMgr site server or DP to see if something got fixed

If you do any of those, let me know how it goes.
Josh Zinnel 0 Reputation points

2025-04-16T18:32:00.7666667+00:00

I have changed PXE variable both in WDS settings and in the registry for those not exposed in the GUI. I am not sure if ConfigMgr even obeys the settings in the GUI or just the registry. But in any event, it didn't fix the issue. The TFTP window setting only takes effect after the NPB step. I saw in WireShark that it was definitely obeying it for the boot.wim download, not before. I've also tried uninstalling the DP's PXE service and reinstalling (our DP is on a separate server). I also had our team spin up a new VM and I configured it as a secondary DP, disabled PXE on the primary DP, and the issue was present on day one with all the default configurations. I don't see a reason to rebuild our primary DP then and I'll just keep the secondary around for redundancy. I reenabled PXE on both. The April cumulative updates are installed but I haven't checked to see if that fixed anything but I doubt it. I can test and reply back. We're going to upgrade ConfigMgr to 2409 this weekend.
Josh Zinnel 0 Reputation points

2025-04-16T18:57:01.3133333+00:00

The April update didn't have any impact. The issue still exists. Occasionally, it does download the NPB file immediately, but usually not.
link470 0 Reputation points

2025-04-16T19:37:32.6266667+00:00

Interesting, thanks for your updates! I think that eliminates the idea of trying to do an uninstall of PXE/WDS and reinstall via the ConfigMgr Console, and that's annoying to hear the April updates didn't solve anything. Let me know how things look after the ConfigMgr 2409 upgrade!
link470 0 Reputation points

2025-04-17T22:51:53.9133333+00:00

What switches/routers are you using, and what kind of networking is between the endpoint and the ConfigMgr server? We have Fortinet, and the only difference I can think of is that at the head office (where the problem exists), the client is behind the FortiGate and the WDS server is on the WAN side in our datacenter, where as at the sites that don't have this problem, the clients and distribution point server are on both behind the FortiGate, and the FortiGate is doing L3 routing between the two.

I'm not expecting this to make a difference because up until now, it hasn't. No networking changes have occurred, and no firmware updates on network devices, and this exact same flow worked prior to March. But something clearly changed.
link470 0 Reputation points

2025-04-24T04:49:01.74+00:00

I'm getting a bit closer. I have an open ticket with Fortinet. For us, the one location this is happening at is where the workstations are on the LAN side of a FortiGate and the ConfigMgr/DP server is on the WAN side (all of our other sites where the DP and workstation are both behind the FortiGate on the LAN side are unaffected). The FortiGate seems to be slowing down the traffic when a TFTP window size of 4 is used (see this article). After performing the mitigation steps and disabling the NPU for the policy that allows the workstations access to the ConfigMgr/DP, the NBP file immediately started downloading quick. Remove the mitigation, and we're back to slow.

Fortinet is trying to figure out why this is happening now. If you're also using Fortinet, this very well may be the problem.

1 answer

Your answer

Josh Zinnel 0 Reputation points

2025-04-03T15:54:53.4866667+00:00

I just spun up a new server and I'm getting the same result with the same test variables. On a Dell 7010 SFF Plus, it first uses a TFTP window of 4 to transmit the NBP file. This sometimes breaks down where not all 4 packages get acknowledged but the client and server start talking past each other and duplicating packets. There's not a particular spot in the 750 or so packets where it breaks down but the longer it goes on, the worse it gets. This server is Windows 2022 vs 2019 for the original so the server OS isn't the issue.
link470 0 Reputation points

2025-04-03T22:31:31.9733333+00:00

I'm running into what sounds like the exact same issue. WDS without MDT, ConfigMgr 2409, Windows Server 2019 and 64GB RAM. Before the 2409 upgrade (when I also installed March 2025 Cumulative Updates on the ConfigMgr server), there was no issues imaging.

I'm unsure if this is a problem introduced with new BIOSs on new hardware, or if this is a problem introduced with Windows Updates in the last few months or going from ConfigMgr 2303 to 2409.

Loading the NBP file takes forever now (where it used to take a second or less). No changes have ever been made to WDSs TFTP variables or any other settings. We simply enabled PXE in ConfigMgr and haven't changed it since. I should also note that it's only the download of the NBP file that seems to cause the WDS memory usage to rise; as soon as that file stops downloading, the tech hits ENTER at the workstation, and the .WIM file starts downloading, the memory usage stops rising for the WDS service. But the memory also doesn't seem to be released either, at least not right away that I've seen. I've had to stop the WDS service and start it again for memory usage to go back down. Even just attempting to image 5 machines will spike the service memory from nothing to almost the entire 64GB of the server, causing the VM to crash and restart.

Any updates Josh?
Josh Zinnel 0 Reputation points

2025-04-04T13:28:16.68+00:00

Scott, unfortunately, no. But our ConfigMgr is on version 2403. We are using WDS as part of ConfigMgr with an MDT enabled task sequence (I know, we will have to migrate off that soon). We are planning to upgrade to 2409 soon. I'm having one of our other sites do the same wireshark capture to see if they're seeing the same thing but they've said they're not having any issues. Our problems started sometime between December and January. No changes were done to ConfigMgr during that time, so it's a Windows update or a network change, I figure. Notably, we had no issue with these models before December, or not detectible anyway. I do not see a way to change the TFTP window for the NBP file, but the settings you set in the registry are obeyed for the boot.wim. For the NBP file, it looks like it negotiates, and the NIC tells it to use a window of 4 but no idea how you control that. I didn't see anything remotely close in the BIOS. It still doesn't explain what changed from Dec to Jan though.

Your description matches what I'm seeing, though 5 computers shouldn't consume 64GB of RAM. Our one server was originally 8 and it could support 4 imaging without crashing. Another thing to check is whether you see the same problem with the same computer repeatedly or only some of the time. I found it sometimes doesn't get stuck in an echo chamber but more than likely it will, sometimes sooner sometimes later. There's about 750 blocks that the server sends. I ran some stats by our network team, and there's only a few hops, 6, which they said was the least amount possible (it wasn't going out of our site or anything). And they had me run MTU tool and said nothing there looked wrong. Jumbo packets were allowed (limit ~9800). Ping times were 1 ms or less.
link470 0 Reputation points

2025-04-04T23:10:58.4666667+00:00

Just to add to this, I've had our techs try the same machines we've been having troubles with (Lenovo M70q Gen 3 and Gen 5 models) out at some of our sites with distribution points at them. The DPs are all also Windows Server 2019, same March 2025 cumulative updates as our main ConfigMgr site server, but 8GB RAM each for those DP servers. Each site they've tested so far performs perfectly and the NBP file does its usual 1 second download or so before the tech hits ENTER and the WIM starts downloading. These DPs with 8GB of RAM can easily handle 30 to 60 machines being imaged at once, and previously, the head office would do that as well.

It just seems to be our head office (where the boot/PXE/DP server is the ConfigMgr site server) that's having these issues. Those Gen 3/Gen 5 M70q machines take a good 5 to 15 minutes to download the NBP file, while RAM spikes on the WDS service on the site server. I found that after the imaging of the machine is done, the service does release the memory, so that's good.

We also tried several other machines (Lenovo L series ThinkPads, an older M93p workstation, a Yoga) and all downloaded the NBP file quickly at the head office, even using the exact same network cable/switch port as the M70q machines that took forever, so the issue seems to be something with the M70q machines, and only at the head office, and only since either recent Windows Updates or our ConfigMgr environment upgrade from 2303 to 2409.

EDIT: For the BIOS versions, we've tried the latest BIOS on the Gen 3 machines, and the stock factory BIOS on the Gen 5 machines as well as latest. No difference. Secure Boot is enabled on all client machines.
Josh Zinnel 0 Reputation points

2025-04-07T21:30:09.63+00:00

Yeah, that lines up with what I've discovered in my environment, except different hardware. Also, our DPs are not on the site server but a dedicated server. Now I understand why you had 64 GB of mem. I found that it can help to increase the virtual memory limit, to a point. Oddly, WDS seems to allocate most of that "memory leak" to virtual memory instead of physical memory, so in Resource Monitor, monitor the "Commit" column. I still can't rule out some kind of network or firewall change, but the preliminary discussion I've had with the network team didn't lead to any insights. I'm still waiting to hear from another site if they're seeing the same pattern in packet captures. Afterwards, I'm out of ideas and will ask my supervisor about opening a Microsoft Support Ticket.
Josh Zinnel 0 Reputation points

2025-04-16T00:14:11.72+00:00

No, I'm afraid I haven't made any additional progress on this issue. I work in education so we haven't started reimaging mass numbers of computers yet, and my time has been spent elsewhere. But yeah, this is frustrating for sure. I didn't see a way to change the TFTP window size on Dell hardware, but I think your experience confirms that setting is the key. No idea what caused the problem though. I'm just as baffled. I've seen other comments like the OP's elsewhere going back years but the threads never zeroed in on TFTP so I do think we're ahead of the game at least. It's like WDS doesn't wait long enough for the replies from the client. If it waited just a millisecond longer, it might never get into the packet race condition. I wonder if slowing down the network link would have any positive impact? I don't know much about WDS but it's got to be a rather old system at this point and probably hasn't seen many changes in a long time. If, historically, at this stage, TFTP always negotiated a window size of 1, you wouldn't bother waiting any longer to send the next packet.
link470 0 Reputation points

2025-04-16T05:10:30.47+00:00

Have you ever changed any PXE variables (window size, block size, any WDS settings, etc.)? Our WDS setup is exactly as ConfigMgr sets it up and nothing else WDS wise has been modified. I did try unchecking the Enable Variable Window Extension checkbox on the TFTP tab in WDS Properties and then restarting WDS, but this didn't make a difference for me, so I set it back to checked.

3 things I can think of trying are:
•Uninstalling and reinstalling PXE on the site server (where our problem exists, as none of our sites/DPs are having the problem)
•Testing the ConfigMgr PXE responder instead of WDS
•Testing the April 2025 cumulative updates on the ConfigMgr site server or DP to see if something got fixed

If you do any of those, let me know how it goes.
Josh Zinnel 0 Reputation points

2025-04-16T18:32:00.7666667+00:00

I have changed PXE variable both in WDS settings and in the registry for those not exposed in the GUI. I am not sure if ConfigMgr even obeys the settings in the GUI or just the registry. But in any event, it didn't fix the issue. The TFTP window setting only takes effect after the NPB step. I saw in WireShark that it was definitely obeying it for the boot.wim download, not before. I've also tried uninstalling the DP's PXE service and reinstalling (our DP is on a separate server). I also had our team spin up a new VM and I configured it as a secondary DP, disabled PXE on the primary DP, and the issue was present on day one with all the default configurations. I don't see a reason to rebuild our primary DP then and I'll just keep the secondary around for redundancy. I reenabled PXE on both. The April cumulative updates are installed but I haven't checked to see if that fixed anything but I doubt it. I can test and reply back. We're going to upgrade ConfigMgr to 2409 this weekend.
Josh Zinnel 0 Reputation points

2025-04-16T18:57:01.3133333+00:00

The April update didn't have any impact. The issue still exists. Occasionally, it does download the NPB file immediately, but usually not.
link470 0 Reputation points

2025-04-16T19:37:32.6266667+00:00

Interesting, thanks for your updates! I think that eliminates the idea of trying to do an uninstall of PXE/WDS and reinstall via the ConfigMgr Console, and that's annoying to hear the April updates didn't solve anything. Let me know how things look after the ConfigMgr 2409 upgrade!
link470 0 Reputation points

2025-04-17T22:51:53.9133333+00:00

What switches/routers are you using, and what kind of networking is between the endpoint and the ConfigMgr server? We have Fortinet, and the only difference I can think of is that at the head office (where the problem exists), the client is behind the FortiGate and the WDS server is on the WAN side in our datacenter, where as at the sites that don't have this problem, the clients and distribution point server are on both behind the FortiGate, and the FortiGate is doing L3 routing between the two.

I'm not expecting this to make a difference because up until now, it hasn't. No networking changes have occurred, and no firmware updates on network devices, and this exact same flow worked prior to March. But something clearly changed.
link470 0 Reputation points

2025-04-24T04:49:01.74+00:00

I'm getting a bit closer. I have an open ticket with Fortinet. For us, the one location this is happening at is where the workstations are on the LAN side of a FortiGate and the ConfigMgr/DP server is on the WAN side (all of our other sites where the DP and workstation are both behind the FortiGate on the LAN side are unaffected). The FortiGate seems to be slowing down the traffic when a TFTP window size of 4 is used (see this article). After performing the mitigation steps and disabling the NPU for the policy that allows the workstations access to the ConfigMgr/DP, the NBP file immediately started downloading quick. Remove the mitigation, and we're back to slow.

Fortinet is trying to figure out why this is happening now. If you're also using Fortinet, this very well may be the problem.

Answer 1

Simon Ren-MSFT 40,411 Microsoft External Staff

Hi,

Hope everything is going well.

1,Similar thread for your reference: Windows Deployment Services Server (WDS) Memory Leak?

The workaround in this thread is:

Open Windows Deployment Services from Windows Administrative Tools. Expand Servers and right-click a WDS server. Open its properties and clear the Enable Variable Window Extension box on the TFTP tab.

If you encounter TFTP perf issue, on the same tab you can try to change the TFTP max block size to one of these value:

1432, 4096, 8192, 16384, 32678

2,If the issue persists, may we know if the secure boot is disabled on the client computers?

3,How are the boot files specified? You may need a different boot file for UEFI ( boot\x64\wdsmgfw.efi ).

Thanks for your time. Have a nice day!

Best regards,

Simon

If the response is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Simon Ren-MSFT 40,411 Reputation points Microsoft External Staff

2025-02-19T01:53:53.5233333+00:00

Hi,

Hope everything goes well. May we know the current status of the question? If there is any other assistance we can provide, please feel free to let us know, we will do our best to help you.

Best regards,

Simon
Simon Ren-MSFT 40,411 Reputation points Microsoft External Staff

2025-02-28T07:15:36.5533333+00:00

Hi,

Hope everything goes well. Do you need any further assistance about this issue? If yes, please feel free to let us know, we will do our best to help you.

If the response is helpful, it's appreciated that you could click "Accept Answer" and upvote it, this will help other users to search for useful information more quickly.

Thanks for your time.

Best regards,

Simon
link470 0 Reputation points

2025-04-16T17:17:46.5333333+00:00

I've tried the suggestion of clearing the Enable Variable Window Extension box, redistributing the boot image, and a bunch of other things, but I haven't found the answer to why this issue has come up yet. Please see the rest of this thread for more info on what we've tried and discovered.

Share via

Memory Leak Issues with Windows Deployment Services (WDS) and MDT Setup

1 answer

Your answer