You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Process is terminating due to StackOverflowException with custom provider on PSModulePath #5565
$path='~/code'
pushd $pathInstall-module SHiPS
git clone https://github.com/DarqueWarrior/vsteam.git
$env:PSModulePath+=";$((resolve-path$path).path)"Import-module vsteam -verbose
Add-TeamAccount-Account <YourVSTSAccountNameOnly>-Drive <DesiredDrive>-Verbose
# Enter your Personal Access Token to VSTS Account
Expected behavior
# Drive will be added
Set-Location <DesiredDrive>:
ls
Actual behavior
Process is terminating due to StackOverflowException.
Environment data
>$PSVersionTable
Name Value
---------
PSVersion 6.0.0-rc
PSEdition Core
GitCommitId v6.0.0-rc
OS Microsoft Windows 10.0.16299
Platform Win32NT
PSCompatibleVersions {1.0,2.0,3.0,4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Workaround
Do not add module path to PSModulePath and the steps below will work.
$path='~/code'
pushd $pathInstall-module SHiPS
git clone https://github.com/DarqueWarrior/vsteam.git
Import-module ./vsteam -verbose
Add-TeamAccount-Account <YourVSTSAccountNameOnly>-Drive <DesiredDrive>-Verbose
# Enter your Personal Access Token to VSTS Account# Drive will be Set-Location<DesiredDrive>:
ls
I was able to replicate the error in 5.1 as well. Donovan Brown (@DarqueWarrior) we never tested with the module on psmodulepath with Windows 5.1 - only loading from off psmodulepath.
The goal was to offer a much easier way to add a drive using the -Drive parameter. As Steve Lee (@SteveL-MSFT) explained if called separately it works fine. I never remember how to call New-PSDrive and have to look it up so I wanted to save the users of VSTeam from the same issue by simply doing it for them with -Drive.
The part that confuses me is the fact that if the module is not on PSModulePath everything works but if it is it breaks.
It looks like there is a circular dependency in handling nestedmodudule (VSTeam=>Team=>VSTeam) if the module path is in the psmodulepath. The problem has been there in Windows PowerShell too.
Details:
The infinite loop is in the GetExportedTypeDefinitions. While new-psdrive, the SHiPS calls “import-module VSTeam; get-module VSTeam” via the PowerShellprovider.SessionState.InvokeCommand.InvokeScript().
Here is my findings about why loading vsteam module from local path works but it does not if under psmodulepath.
Import-module vsteam from a local path. This case works fine. From my watch window, you can see VSTeam has a nestedmodule, Team but it has no nestedmodules.
While VSTeam module is in the psmodulepath, from the debugger you can see VSteam has NestedModule, Team, which a nestedmodule, VSTeam, which is causing module loading infinitely.
Stack
System.Management.Automation.dll!System.Management.Automation.PSModuleInfo.GetExportedTypeDefinitions() Line 580 (e:\powershell\src\System.Management.Automation\engine\Modules\PSModuleInfo.cs:580)
System.Management.Automation.dll!System.Management.Automation.AnalysisCache.CacheModuleExports(System.Management.Automation.PSModuleInfo module, System.Management.Automation.ExecutionContext context) Line 465 (e:\powershell\src\System.Management.Automation\engine\Modules\AnalysisCache.cs:465)
System.Management.Automation.dll!Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadUsingModulePath(System.Management.Automation.PSModuleInfo parentModule, bool found, System.Collections.Generic.IEnumerable<string> modulePath, string name, System.Management.Automation.SessionState ss, Microsoft.PowerShell.Commands.ModuleCmdletBase.ImportModuleOptions options, Microsoft.PowerShell.Commands.ModuleCmdletBase.ManifestProcessingFlags manifestProcessingFlags, out System.Management.Automation.PSModuleInfo module) Line 345 (e:\powershell\src\System.Management.Automation\engine\Modules\ModuleCmdletBase.cs:345)
System.Management.Automation.dll!Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadUsingModulePath(bool found, System.Collections.Generic.IEnumerable<string> modulePath, string name, System.Management.Automation.SessionState ss, Microsoft.PowerShell.Commands.ModuleCmdletBase.ImportModuleOptions options, Microsoft.PowerShell.Commands.ModuleCmdletBase.ManifestProcessingFlags manifestProcessingFlags, out System.Management.Automation.PSModuleInfo module) Line 276 (e:\powershell\src\System.Management.Automation\engine\Modules\ModuleCmdletBase.cs:276)
System.Management.Automation.dll!Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName(Microsoft.PowerShell.Commands.ModuleCmdletBase.ImportModuleOptions importModuleOptions, string name) Line 708 (e:\powershell\src\System.Management.Automation\engine\Modules\ImportModuleCommand.cs:708)
System.Management.Automation.dll!Microsoft.PowerShell.Commands.ImportModuleCommand.ProcessRecord() Line 1731 (e:\powershell\src\System.Management.Automation\engine\Modules\ImportModuleCommand.cs:1731)
System.Management.Automation.dll!System.Management.Automation.Cmdlet.DoProcessRecord() Line 177 (e:\powershell\src\System.Management.Automation\engine\cmdlet.cs:177)
System.Management.Automation.dll!System.Management.Automation.CommandProcessor.ProcessRecord() Line 360
Looking at the code in GetExportedTypesDefinitions, it appears to be a TODO to handle circular dependencies and caching nested module types. We should fix this in 6.1, but existing usage will need to use the workaround particularly if targeting Windows PowerShell 5.1 as well.
I just want to confirm that the circular dependencies are implicit and not explicit correct? I don't see where I am referencing the two modules against each other explicitly.
Donovan Brown (@DarqueWarrior) yes, it is implicit due to how SHiPS calls back into the module to access the class since we don't supported exposing classes via ExportedTypes yet.
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 23, 2023
Activity
SteveL-MSFT commentedon Nov 28, 2017
This repros in Windows PowerShell 5.1 so it's not due to any changes we've made in PSCore6
SteveL-MSFT commentedon Nov 28, 2017
My hypothesis is that the VSTeam module calls into SHiPs module which in turn calls VSTeam module, etc... until stack runs out. cc Jianyun (@jianyunt)
usepowershell commentedon Nov 28, 2017
I was able to replicate the error in 5.1 as well. Donovan Brown (@DarqueWarrior) we never tested with the module on psmodulepath with Windows 5.1 - only loading from off psmodulepath.
jianyunt commentedon Nov 29, 2017
Something is "wrong" in the steps below so I cannot repro it?
iSazonov commentedon Nov 29, 2017
We have related Issue with discussions about reloading nested modules. #2505
SteveL-MSFT commentedon Nov 29, 2017
Jianyun (@jianyunt) it doesn't repro if you call
new-psdriveoutside of the module. it only overflows ifnew-psdriveis called within the module:DarqueWarrior commentedon Nov 29, 2017
The goal was to offer a much easier way to add a drive using the -Drive parameter. As Steve Lee (@SteveL-MSFT) explained if called separately it works fine. I never remember how to call New-PSDrive and have to look it up so I wanted to save the users of VSTeam from the same issue by simply doing it for them with -Drive.
The part that confuses me is the fact that if the module is not on PSModulePath everything works but if it is it breaks.
SteveL-MSFT commentedon Nov 29, 2017
cc Hemant Mahawar (@HemantMahawar)
jianyunt commentedon Nov 30, 2017
It looks like there is a circular dependency in handling nestedmodudule (VSTeam=>Team=>VSTeam) if the module path is in the psmodulepath. The problem has been there in Windows PowerShell too.
Details:
The infinite loop is in the GetExportedTypeDefinitions. While new-psdrive, the SHiPS calls “import-module VSTeam; get-module VSTeam” via the PowerShellprovider.SessionState.InvokeCommand.InvokeScript().
Here is my findings about why loading vsteam module from local path works but it does not if under psmodulepath.
Import-module vsteam from a local path. This case works fine. From my watch window, you can see VSTeam has a nestedmodule, Team but it has no nestedmodules.

While VSTeam module is in the psmodulepath, from the debugger you can see

VSteamhas NestedModule,Team, which a nestedmodule,VSTeam, which is causing module loading infinitely.Repro steps
Recommended workaround:
I think by separating teamspsdrive from vsteam module will likely workaround the problem.
SteveL-MSFT commentedon Nov 30, 2017
Looking at the code in GetExportedTypesDefinitions, it appears to be a TODO to handle circular dependencies and caching nested module types. We should fix this in 6.1, but existing usage will need to use the workaround particularly if targeting Windows PowerShell 5.1 as well.
DarqueWarrior commentedon Dec 6, 2017
I just want to confirm that the circular dependencies are implicit and not explicit correct? I don't see where I am referencing the two modules against each other explicitly.
SteveL-MSFT commentedon Dec 6, 2017
Donovan Brown (@DarqueWarrior) yes, it is implicit due to how SHiPS calls back into the module to access the class since we don't supported exposing classes via ExportedTypes yet.
rjmholt commentedon Feb 23, 2021
Was this issue fixed in #6843?
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.