Possible FormatEnumerationLimit related bug

Can anybody else confirm the following? Start PowerShell with no profile
(-noprofile). Execute this:

[system.reflection.assembly]::LoadWithPartialName("System.Windows.Forms") |
fc

It should not hang. Now set the following variable:

$FormatEnumerationLimit = 100

Execute the first command again:

[system.reflection.assembly]::LoadWithPartialName("System.Windows.Forms") |
fc

It hangs on my system chewing up 100% CPU. This was reported as a PSCX bug
but I think it is a PowerShell bug that gets surfaced because the PSCX
profile sets the FormatEnumerationLimit to 100.

--
Keith

Keith,

I do not think this is a bug, as format-custom does enumerate everything,
and you did remove the safety belt's (enumerationlimit )

any idea how big this output is ? (all Namespaces in the form namespace,
including all properties etc,)

try raising the limit one by one to get a basic idea ;-)

Greetings /\/\o\/\/

"Keith Hill [MVP]" wrote:

> Can anybody else confirm the following? Start PowerShell with no profile
> (-noprofile). Execute this:
>
> [system.reflection.assembly]::LoadWithPartialName("System.Windows.Forms") |
> fc
>
> It should not hang. Now set the following variable:
>
> $FormatEnumerationLimit = 100
>
> Execute the first command again:
>
> [system.reflection.assembly]::LoadWithPartialName("System.Windows.Forms") |
> fc
>
> It hangs on my system chewing up 100% CPU. This was reported as a PSCX bug
> but I think it is a PowerShell bug that gets surfaced because the PSCX
> profile sets the FormatEnumerationLimit to 100.
>
> --
> Keith
>
>

"/\/\o\/\/ [MVP]" <oMVP@discussions.microsoft.com> wrote in message
news:6AA8E2DC-4A63-410B-8ADE-ADF482812E71@microsoft.com...
> Keith,
>
> I do not think this is a bug, as format-custom does enumerate everything,
> and you did remove the safety belt's (enumerationlimit )
>
> any idea how big this output is ? (all Namespaces in the form namespace,
> including all properties etc,)
>
> try raising the limit one by one to get a basic idea ;-)

I dunno - raising it from its default of 4 to 5 causes PowerShell to spin
the CPU to 100% and this command still hasn't completed after a few
*minutes*. I believe it is the assembly evidence hash of WinForm's
ManifestModule that it is getting hung up on.

--
Keith

"/\/\o\/\/ [MVP]" <oMVP@discussions.microsoft.com> wrote in message news:6AA8E2DC-4A63-410B-8ADE-ADF482812E71@microsoft.com...
> Keith,
>
> I do not think this is a bug, as format-custom does enumerate everything,
> and you did remove the safety belt's (enumerationlimit )

BTW the point of doing this was to get a bit more useful output e.g. instead of this:

Name : DigitalPersona, Inc.
Count : 55
Group : {DPAgnt, DPAgnt, DPAgnt, DPAgnt...}
Values : {DigitalPersona, Inc.}

I want to see this:

Name : DigitalPersona, Inc.
Count : 55
Group : {DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgn
t, DPAgnt, DPAgnt, dwm, EDICT, EDICT, EDICT, ehmsas, ehtray, explorer,
FlashUtil9b, ieuser, iexplore, iexplore, iexplore, iexplore, iexplore
, iexplore, iexplore, iexplore, iexplore, iexplore, iexplore, ipoint,
itype, mobsync, msnmsgr, powershell, ProxyEnableSwitch2.0, rundll32, s
idebar, sidebar, sidebar, taskeng, taskmgr, unsecapp, Virtual PC, vVX6
000, WinMail, WinMail, WinMail, winssnotify, WLLoginProxy, wmdc, wmpns
cfg, wuauclt, ZuneLauncher}
Values : {DigitalPersona, Inc.}

When I execute something like:

gps | select ProcessName -expand Modules -ea silentlycontinue | group Company | fl

Now that I think about it perhaps the default value of 4 for FormatEnumerationLimit was chosen because of either a bug or unboound CPU consumption in PowerShell 1.0. Because it has always struck me that this display:

Group : {DPAgnt, DPAgnt, DPAgnt, DPAgnt...}

is ridiculously limited to be the "default" display.

--
Keith

Actualy, I was one of the guy's asking for this limit (for datatables and
ADSI / SMS work ) back in Beta 2, as it is most of the time not handy to get
all fields back.


Greetings /\/\o\/\/

"Keith Hill [MVP]" wrote:

> "/\/\o\/\/ [MVP]" <oMVP@discussions.microsoft.com> wrote in message
> news:6AA8E2DC-4A63-410B-8ADE-ADF482812E71@microsoft.com...
> > Keith,
> >
> > I do not think this is a bug, as format-custom does enumerate
> everything,
> > and you did remove the safety belt's (enumerationlimit )
>
> BTW the point of doing this was to get a bit more useful output e.g.
> instead of this:
>
> Name : DigitalPersona, Inc.
> Count : 55
> Group : {DPAgnt, DPAgnt, DPAgnt, DPAgnt...}
> Values : {DigitalPersona, Inc.}
>
> I want to see this:
>
> Name : DigitalPersona, Inc.
> Count : 55
> Group : {DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgnt, DPAgnt,
> DPAgn
> t, DPAgnt, DPAgnt, dwm, EDICT, EDICT, EDICT, ehmsas, ehtray,
> explorer,
> FlashUtil9b, ieuser, iexplore, iexplore, iexplore, iexplore,
> iexplore
> , iexplore, iexplore, iexplore, iexplore, iexplore, iexplore,
> ipoint,
> itype, mobsync, msnmsgr, powershell, ProxyEnableSwitch2.0,
> rundll32, s
> idebar, sidebar, sidebar, taskeng, taskmgr, unsecapp, Virtual PC,
> vVX6
> 000, WinMail, WinMail, WinMail, winssnotify, WLLoginProxy, wmdc,
> wmpns
> cfg, wuauclt, ZuneLauncher}
> Values : {DigitalPersona, Inc.}
>
> When I execute something like:
>
> gps | select ProcessName -expand Modules -ea silentlycontinue | group
> Company | fl
>
> Now that I think about it perhaps the default value of 4 for
> FormatEnumerationLimit was chosen because of either a bug or unboound CPU
> consumption in PowerShell 1.0. Because it has always struck me that this
> display:
>
> Group : {DPAgnt, DPAgnt, DPAgnt, DPAgnt...}
>
> is ridiculously limited to be the "default" display.
>
> --
> Keith
>