Powershell ISE, geen breakpoints als admin

[Blokker_1999]

Mijn vraag

Ik heb een script dat als admin uitgevoerd zal moeten worden omdat het enkele systeeminstellingen en regkeys zal aanpassen. Ik loop tegen enkele probleempjes aan en wil dit script dus debuggen via bijvoorbeeld Powershell ISE.

Als ik ISE als admin start, dan kan ik evenwel geen breakpoints zetten. De lijn selecteren en op F9 duwen geeft geen resultaat. Wil ik het via de command line doen met set-psbreakpoint krijg ik de melding "Specified method is not supported."

Relevante software en hardware die ik gebruik

Windows 10 1909 met Powershell 5.1 in een VM die net opnieuw gebouwd is. Local admin of domain user maakt niet uit.

Wat ik al gevonden of geprobeerd heb

Het is een probleem dat blijkbaar wel eens voorkomt, maar de weinige posts die ik online kan vinden wijzen naar problemen met bijvoorbeeld het niet lokaal hebben opgeslagen van het script wat hier niet het geval is. Ik kan het op andere systemen wel uitvoeren, maar daar heb ik niets aan de aanpassingen die het script probeert door te voeren. Maar ISE struikelt dus niet over het script.

[MAX3400]

Long shot maar komt je locale wel overeen met mogelijke waarden / uitvoer in het script? Niet dat jij bijvoorbeeld YY/MM/dd praat en het script ervanuit gaat (zonder declaratie) dat je YY/dd/MM hebt.

[Blokker_1999]

De locale zeker niet. Die wordt, tot mijn grote ergernis, geforceerd via een logon script. For the love of God, why!!!!

[_360_]

Heb je dit ook al onder powershell core met visual studio code proberen te debuggen?

[Blokker_1999]

Yep, maar die wil ook niet werken door een verschil in language modes. En dat klopt ook doordat er enkele cmdlets gebruikt worden die niet ondersteund worden in pwsh.

En als ik met posh probeer te debuggen in vs code dan probeert het script wel te starten, maar begint nooit echt iets uit te voeren.

[ Voor 29% gewijzigd door Blokker_1999 op 21-01-2022 09:05 ]

[_360_]

Het blijft een gissen zolang we geen code zien.

Even om te verifieren: we hebben het hier over een .ps1 file, geen powershell module oid?
Gaat het ook fout als je het script op je eigen host machine debugged met powershell_ise?

Voor de oefening zou je een kunnen beginnen met een nieuw leeg script, die je wil kan debuggen. En dan stuk voor stuk de functionaliteit overbrengen todat je evt. weer tegen ditzelfde probleem aanloopt.

Daarnaast kan je ipv

code:

set-psbreakpoint

ook eens

code:

Wait-Debugger

proberen.

[Blokker_1999]

Nog altijd niet de root cause gevonden, maar begin wel dichtbij te komen. Vandaag met procmon aan de slag gegaan.

Powershell en pwsh gaan bij het opstarten kijken of ze in je temp pad een script kunnen zetten en uitvoeren. Als dit faalt dan krijg je automatisch een constrained language mode. En die modus zorgt voor heel wat problemen, waaronder dus dat je niet kunt debuggen.

Is mijn pad dan niet geldig? Jawel. Maar ... de gebruikersnaam waarmee ik dit probeer is langer dan 8 karakters en wordt verwerkt in hoe MS met paden omgaat waarbij de ene applicatie de naam volledig uitschrijft terwijl een ander systeem probeert om het tot 8 tekens te beperken, bijv. Blokke~1. En daarop loopt het dus mis.

Als ik mijn environment variable aanpas naar een eenvoudig fixed pad zoals c:\temp dan kom ik terug in full language mode terug.

Wat er veranderd is weet ik niet. Want ben nu ook op andere systemen tegen dit probleem aangelopen toen dat daar een script ineens stopte met werken om dezelfde reden. Mogelijks een update die MS gepushed heeft waardoor er ergens iets veranderd is. Daar moet ik nog verder naar kijken.

Dat het dus als admin niet lukt komt omdat mijn admin account een langere naam heeft dan mijn gewone username die wel beperkt is tot onder de 8 karakters.