I found a huge memory leak in project which appears after execution PS command. Here I create example that represent my problem in "TestCase" comment.

After memory usage investigation I found that most of memory occupied by inner structures from System.Management.Automation. So I start to search the way to release resources and found that the same behavior can be reproduced in PS:
Get-Module -ListAvailable | ForEach { Import-Module $_.Name }
Get-Command -ListImported -CommandType Cmdlet,Alias

I already have tried to initiated garbage collecting and to remove all new variables that appears after script execution. I even have tried to start new Runspace into PowerShell ISE to run script, but resources still didn't release.

During my research I found that this code still eat a bunch of memory. You can see it in "TestLeak" comment. But if we change this:
Get-Process *
to this:
$res = Get-Process *
then memory doesn't leak. Variable goes out of scope and then freed up by garbage collector. But in first case it looks like PowerShell stores results somewhere in inner structures. I have tried to add variable to my script to store cmdlet's results but nothing changed like my variable never goes out of scope!

I can't free memory no matter what I do! Do I do something wrong or it is some kind of problem?

P.S. Error appears when I try to attach the files so add code as comments!

I can't use power shell. If I open it, print these error
ハンドルされていない例外: System.Runtime.InteropServices.SEHException: 外部コンポーネントが例外をスローしました。
場所 System.Reflection.RuntimeAssembly.GetResource(RuntimeAssembly assembly, String resourceName, UInt64& length, StackCrawlMarkHandle stackMark, Boolean skipSecurityCheck)
場所 System.Reflection.RuntimeAssembly.GetManifestResourceStream(String name, StackCrawlMark& stackMark, Boolean skipSecurityCheck)
場所 System.Resources.ManifestBasedResourceGroveler.GetManifestResourceStream(RuntimeAssembly satellite, String fileName, StackCrawlMark& stackMark)
場所 System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)
場所 System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark)
場所 System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
場所 System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
場所 System.Management.Automation.Internal.PipelineProcessor.Start(Boolean incomingStream)
場所 System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
場所 System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper()
場所 System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()
場所 System.Management.Automation.Runspaces.PipelineThread.WorkerProc()
場所 System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
場所 System.Threading.ThreadHelper.ThreadStart()

Problem Description
------------------
If you are using the `using module` statement, it will load the module without any issues. However, if you make a change to the module and run the `using module` statement again without restarting your PowerShell session, it will not load the new modified module into memory, and instead will continue to use the old existing module that was loaded. This makes doing development with `using module` statements very tedious as you must continually reload your PowerShell session whenever you make changes to the module.

Ideally we would just use `Import-Module -Name [module name] -Force` to avoid this issue, but that does not work for importing `class`es, so the `using module` statement **must** be used.

Steps to reproduce
------------------
Create the following module and script files:

In `TestModule.psm1`:
```powershell
class TestClass
{
[string] $ClassPropertyText = "Initial text"
}

function Get-ModuleFunctionText()
{
return "Initial text"
}

Export-ModuleMember -Function Get-ModuleFunctionText
```

In `Test.ps1`:
```powershell
using module '.\TestModule.psm1'

$instance = [TestClass]::new()
$instance.ClassPropertyText

Get-ModuleFunctionText
```

Run `Test.ps1` and it will output:
```
Initial text
Initial text
```

Then modify `TestModule.psm1` to:
```powershell
class TestClass
{
[string] $ClassPropertyText = "Updated text"
}

function Get-ModuleFunctionText()
{
return "Updated text"
}

Export-ModuleMember -Function Get-ModuleFunctionText
```

Run `Test.ps1` again and it will still output:
```
Initial text
Initial text
```

Expected behavior
-----------------
When running `Test.ps1` the 2nd time, it should output:
```none
Updated text
Updated text
```

Environment data
----------------

<!-- provide the output of $PSVersionTable -->

```powershell
> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.17134.228
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17134.228
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
```

Additional Info
----------------
The problem can be somewhat reduced by using _both_ the `using module` statement and `Import-Module -Force` statement, like this:
```powershell
using module '.\TestModule.psm1'
Import-Module -Name '.\TestModule.psm1' -Force

$instance = [TestClass]::new()
$instance.ClassPropertyText

Get-ModuleFunctionText
```

This code would result in the following output:
```
Initial text
Updated text
```

So here the module code was updated, but the `class` code was not.

Proposed Solution
----------------
To fix this issue I propose adding a `-Force` flag to the `using module` statement that forces the module to be reloaded into memory; the same way that the `-Force` flag works for the `Import-Module` cmdlet. This will allow developing code that uses the `class` construct to work much smoother.

I also proposed this same change to PowerShell Core at: https://github.com/PowerShell/PowerShell/issues/7654

If I try to find when the user abc.cd logon to my computer.
I will do a log query as follow.
Get-WinEvent -FilterHashtable @{logname='security';data='abc.cd';id=4624}

If I want to know when a software was install on computer.
I will do a log query as follow.
Get-WinEvent -FilterHashtable @{logname='application';id=11707}

but It does not work with a user ID as follow.
Get-WinEvent -FilterHashtable @{logname='application';id=11707;data='abc.cd'}

What I do I want is collectting all logs that caused by the user abc.cd by using get-winevent , like he installs a new software , he starts a service ,he starts a scheduled task ..

expected cmdlet:
Get-WinEvent -FilterHashtable @{logname=alllog;user='abc.cd'}

# Steps to reproduce
1. I use a tool called rabtap to publish messages to rabbitMQ. Tool can be found here: https://github.com/jandelgado/rabtap
2. When I tap on an exchange and redirect output to a file.
-> It comes OK when I use this cmd on cmd prompt (i.e., as here): rabtap tap "myexchange:" --json > c:\tmp\usingCMDline.txt"
-> However if I redirect the output using powershell, I miss out the ending bracekt in the output file. rabtap tap "myexchange:" --json | Out-File "c:\tmp\ps02.txt" (see attached output)
# Expected behavior
Full JSON should output, as done by the cmd line redirect operator.

# Actual behavior
Miss out on the ending bracket.
More details on issues can be seen here: https://github.com/jandelgado/rabtap/issues/21

This looks like a bug on first sight but maybe there is a workaround that I am missing? Any idea why this is happening?

# Environment data

Currently module imports initiated via the RequiredModules statement in a Module Manifest do not allow for verbosity preference.

This results in a lot of additional noise for end users.
For example. If a DSC Resource module requires other modules, and imports them via RequiredModules in the Module Manifest then the following happens:

If an end-user is attempting to troubleshoot their DSC configuration they will utilize

Start-DscConfiguration -UseExisting -Verbose -Force

The results will be a verbose line for every cmdlet imported/exported from every included module. Which is A LOT of noise surrounding the verbose messages actually relevant to the end user.

There should be a way to avoid this. Something like this:

RequiredModules = @(@{ModuleName = "MSOnline"; ModuleVersion = "1.1.183.17"; Verbose:$false })

Currently there is no built in or easy way to have credentials stored to map persistent Drives via a script.

If you are mapping a drive for the same domain that the system is on then it will pass-through the current user's credentials, and it will save alternate credentials for the mapping in the current user session. However if you are trying to map a persistent drive for a share from a different non-federated domain, a workgroup computer, or for something on the same domain using different credentials, the password is not saved through logouts or reboots. Not only is the password not saved, but unless you manually put the credentials in Credential Manager (currently no native PS commands to do this, if you're scripting need to use the old Cmdkey commands) it will lockout the username specified in the credentials by trying to login with a blank password several times.

See here for a more detailed explanation of the mechanics and issue:
https://www.bloggingforlogging.com/2018/11/22/windows-mapped-drives-what-the-****-is-going-on/

I suggest that the New-PSDrive command be updated so that it adds the credentials to Credential Manager if both the -Persist and -Credential options are specified.

This would result in the expected behaviour of the drives being persistent through logouts and reboots, mirror the current behaviour when the drive is mapped via the GUI, and fix the account lockout issue that this can cause.