#Requires -Modules causes memory leak

[danielniccoli]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

1. Create the file memoryleak.ps1 with the following content:

#Requires -Version 7
#Requires -Modules @{ ModuleName="Microsoft.Graph"; ModuleVersion="2.24.0" }

[CmdletBinding()]
param (
    [Parameter()]
    [switch]
    $SayHello
)

if ($SayHello) {
    "Hello!"
} else {
    "I say nothing!"
}

2. Install the dependency Microsoft.Graph.
3. Enter into the terminal: memoryleak.ps1 -
4. Press tab (for autocompletion).

Expected behavior

Autocompletion should find parameter `-SayHello'

Actual behavior

1. Autocompletion will not finish.
2. The current pwsh.exe process starts consuming more and more memory (over 2GB in my case).

Error details

Not available as process must be killed.

Environment data

Name                           Value
----                           -----
PSVersion                      7.4.6
PSEdition                      Core
GitCommitId                    7.4.6
OS                             Microsoft Windows 10.0.26100
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

The upper process is the relevant one:

[kilasuit]

You've picked one of the biggest and most painful modules for a usecase.

As such I would suggest trying the same either a smaller module, or a subset of the modules that are bundled with Microsoft.Graph (as it's a meta-module) because you most likely will never need them all of the sub modules it contains loaded at the same time, in the same active session, same applies with Az or AWS modules too.

But what's happening under the hood is that the engine is saying we have to have this module available before we can do anything further and as you aren't in this particular instance actually using that module why would you have that as the requires statement? But again whats happening is the engine is going I need this, do I have this & if so load it ready for use & the consumption of RAM is due to it loading in all of the Modules contained in the Microsoft.Graph Module.

You'd should find this will eventually load everything needed, if your system can handle it, and then allow you eventually to tabcomplete as exepected (which on my Surface Go 3 it did eventually with 7.4.6)

I used this as a tester side by side as it's a much simpler module that I had on this device.

#Requires -Version 7
#Requires -Modules @{ ModuleName="MSI"; ModuleVersion="3.3.4" }

[CmdletBinding()]
param (
    [Parameter()]
    [switch]
    $SayHello
)

if ($SayHello) {
    "Hello!"
} else {
    "I say nothing!"
}

which gives tabcompletion as expected

I think the real issue here is that we perhaps it goes against an expectation that we shouldn't be trying to load modules at this point and should load them on execution only, but that's powershell trying it's best to be ready for you to actually say Yes I'm actually gonna run this & not just I was thinking about running this

This might be a by design, because we do want you to get things done as quick as possible.
Gonna have the Engine WG have a review of this & see if there's anything else we can do here in future.

but the crux, only put in the modules needed in a #Requires statement and not a Meta-Module that bundles lots of modules all together.

[MartinGC94]

What happens if you run Import-Module -FullyQualifiedName @{ ModuleName="Microsoft.Graph"; ModuleVersion="2.24.0" }? Does it get stuck the same way as well? If so then it's not a problem with requires or tab completion but instead the module import process.

[SamErde]

As this issue remains open, I will simply support what @kilasuit stated: importing the Microsoft.Graph module will automatically import all Graph sub-modules, which takes a couple of minutes on average on my machine. This delay may look like a memory leak but is more likely just memory being consumed by the loading of all Microsoft.Graph sub-modules. Instead of using #requires Microsoft.Graph, you may find it more efficient to require the specific sub-modules used by your script.

[mdsharpe]

This is still a problem in 2026.

#Requires -modules Microsoft.Graph causes terminal to become unresponsive.

#Requires -modules Microsoft.Graph.Authentication appears to be an acceptable workaround.

[SamErde]

This is still a problem in 2026.

#Requires -modules Microsoft.Graph causes terminal to become unresponsive.

#Requires -modules Microsoft.Graph.Authentication appears to be an acceptable workaround.

The problem still is not a memory leak, but simply poor documentation. The statement #Requires -Modules Microsoft.Graph should almost never exist in the real world because it forces nearly 50 modules to be loaded into memory before the rest of the code even begins to run.

The #Requires statement should always be specific about while sub-modules are required. You usually only need one or two (e.g., #Requires -Modules 'Microsoft.Graph.Authentication').

[danielniccoli]

I left this issue open because, while I acknowledge that this may not technically be a memory leak, I didn’t have the bandwidth to follow up on the suggested investigations yet.

However, arguing that this behaviour is acceptable simply because it involves importing all of Microsoft.Graph misses the key point. Whether this is a good or bad example is irrelevant. Importing any module should not cause PowerShell to consume gigabytes of memory — especially when the actual module being loaded represents only a fraction of the total memory PowerShell balloons to. That is, quite frankly, unreasonable behaviour for a core platform feature.

And yes, importing only the specific Microsoft.Graph sub-modules would likely improve performance. But my key point still stands: users should not have to carefully micromanage module imports just to avoid excessive memory usage. Module loading should be efficient and predictable, regardless of module size.

[mdsharpe]

Perhaps I am not appreciating the nuances of #Requires -Modules, but my understanding is I should be able to use it to simply check that a given module is installed as a prerequisite to my script being run. I cannot see anything in the documentation warning that it will load the modules in order to check they are installed, and indeed this is also not intuitive.

Ideally in my opinion PowerShell should not be doing such a lot of heavy lifting to check if modules are installed, and, if it must, then the documentation should warn as such.

[MartinGC94]

The purpose of #Requires -Modules is to tell PowerShell (and the end user) that the script needs certain modules to function. If you don't want it to import the modules immediately, then when do you want the import to happen? Should it happen dynamically as if you hadn't specified #Requires -Modules at all?
In that case, let's imagine a scenario where someone has installed all the correct modules, but one of them cannot be imported for some reason (assembly conflict, execution policy restriction, corrupt .dll, etc.). The problematic module is only used halfway through the script. In that case the script runs halfway through and then errors out due to the missing module. That kinda defeats the purpose of making the script robust by declaring the dependencies up front IMO.

[mdsharpe]

Fair point, and an argument for being more specific about the required modules.

I guess, though, ultimately it's not obvious as a script author that you can't say #Requires -modules Microsoft.Graph as shorthand for "you need to install Microsoft.Graph before you run this script", which is what you would say to a colleague in real life. All the Microsoft documentation refers to "the Microsoft.Graph module", so it is clearly intended to be thought of as a homogenous blob at least some of the time.