In CTP2 of PowerShell v2, we added a new parameter to Get-Help: Online. This parameter lets help authors declare an “online version” of their help topic, which PowerShell then launches with your default browser. For the PowerShell cmdlet help topics, we redirect to the excellent (and more frequently updated) online cmdlet help topics: http://technet.microsoft.com/en-us/library/dd347701.aspx.

PowerShell supports online help content for both MAML-based help topics (http://msdn.microsoft.com/en-us/library/bb525433(VS.85).aspx, http://blogs.msdn.com/powershell/archive/2006/09/14/Draft-Creating-Cmdlet-Help.aspx, http://blogs.msdn.com/powershell/archive/2008/12/24/powershell-v2-external-maml-help.aspx) and inline help comments (http://technet.microsoft.com/en-us/library/dd819489.aspx.)

To add support for the –Online parameter to your own cmdlet help, add a maml:navigationLink element with a maml:uri node to the maml:relatedLinks section in your MAML help. The help system uses the first navigation link that contains a URI as the target for the link.

<maml:relatedLinks>
              <maml:navigationLink>
                     <maml:linkText>Online version:</maml:linkText>
                     <maml:uri>http://go.microsoft.com/fwlink/?LinkID=113279</maml:uri>
              </maml:navigationLink>
(…)
</maml:relatedLinks>

When writing comment-based help, use the .LINK tag for the same effect:

001 002 003 004 005 006 007 008

## .SYNOPSIS ## Gets an object from the system ## .LINK ## http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx function   Get-MyObject {     "Hello!" }

For more information about this feature, see Get-Help Get-Help –Parameter Online.

There are a few. Based on worldwide numbers (160 confirmed deaths, 3000 “suspected” cases)

• Falling out of bed (900 confirmed deaths)
• Falling down the stairs (1,690 confirmed deaths)
• Big storm (874 confirmed deaths)
• Drinking binge (346 confirmed deaths)

Of course, the statistic left out by the news

• Normal flu (36,000 confirmed deaths per year)

http://www.nsc.org/research/odds.aspx

I got forwarded an addictive interactive sequencer yesterday (http://lab.andre-michelle.com/tonematrix) and was immediately hooked. I asked an internal mailing list if there was any kind of hardware that lets you do this kind of thing on the couch, and got the response -- “you mean MIDI?” That’s close, but it is closer to a very simplified sequencer.

I play classical guitar... even being a fan of electronic music, I had never seen a sequencer used, or tried to make anything in one. I’m sure some researcher out there would love to have me for a “out of touch with reality” anthropology study.

Then I wondered, “Why should GUI folks have all the fun?”

88 lines later, a PowerShell Sequencer / Tracker was born: http://www.leeholmes.com/projects/PsTracker/PsTracker.zip. Even as a jaded scripter, I’m constantly amazed how compact PowerShell is. Given an example input:

# Replace any dash with something else to make a sound in that spot.
# Format: <NOTE><OCTAVE> <PATTERN>
# If you restrict yourself to a pentatonic scale (i.e. CDEGAC), anything sounds good.
# Instruments: # ([Toub.Sound.Midi.GeneralMidiInstruments] | gm -static -mem Property | % { $_.Name } ) -join " "

# .Instrument OverdrivenGuitar

C5 ---------OO-OO--
A5 -------OO-OO---O
G4 --------------O-
E4 ----------------
D4 X---X---X---X---
C4 ----------------
A4 ----------------
G3 ----X-----------
E3 ----------------
D3 ----------------
C3 ----------------
A3 -------OO-OO----
G2 ----------------
E2 ----------------
D2 ----------------
C2 ----------------

# .Instrument SquareLead
C6 -X-X-XX-X--XXX

# .Instrument Ocarina
C7 ---------------X-X-XX-X--XXX

# .Instrument Kalimba
C8 -----------------X---X---X---X--

This is all it takes to process it:

For example:

.\Start-Tracker track.txt 60

If your system has a MIDI instrument for “Cowbells,” make sure to add more of them! This script builds on Stephen Toub's MIDI library, which I can't seem to find a reference to any longer.

As an aside, that research junket eventually led me to playing with a more feature-rich (free) sequencer called Linux Multimedia Studio. Keeping with the basis of starting with a pentatonic scale, this took only about an hour or two: http://www.leeholmes.com/projects/PsTracker/strive.mp3.

Ibrahim just posted something to the PowerShell blog about how to create tied variables in PowerShell. If you extend this approach with script blocks, you have a very powerful dynamic scripting technique.

PS C:\temp> cd \temp
PS C:\temp> New-ScriptVariable.ps1 GLOBAL:lee { $myTestVariable } { $GLOBAL:myTestVariable = 2 * $args[0] }
PS C:\temp> $lee
PS C:\temp> $lee = 10
PS C:\temp> $lee
20
PS C:\temp> New-ScriptVariable.ps1 GLOBAL:today { (Get-Date).DayOfWeek }
PS C:\temp> $today
Wednesday
PS C:\temp> New-ScriptVariable.ps1 GLOBAL:random -Get { Get-Random } -Set { Get-Random -SetSeed $args[0] }
PS C:\temp> $random
1740776676
PS C:\temp> $random
1507521897
PS C:\temp> $random = 10
PS C:\temp> $random
1613858733
PS C:\temp> $random = 10
PS C:\temp> $random
1613858733

He alluded to it in the post – here is the full text of the script:

(Edit 05/17: Updated to make the getters more like PowerShell pipelines: return a single object, or collection of PSObject)

We've started working on the next edition of the PowerShell Cookbook, and one obvious goal is to improve on the first version.

As the first version has been in print, I've taken notes on where people get confused with certain recipes. I've taken notes on what I felt were content gaps, and taken the feedback from reviews on Amazon.com and random blogs. Reviews on Amazon are GOLD for authors. They help readers form educated opinions, and provide helpful feedback about the book itself. If you want to thank the author of a book you like, write a review on Amazon.

The second edition of the PowerShell Cookbook continues in the same tradition as the first. Topical, real-world solutions to everyday problems. Packed with an appendix of reference material that matters. It will continue to be a purposefully distinct approach from PowerShell in Action.

With that, here's your chance to influence the next edition. What did you find too basic? Too advanced? Missing altogether? Were there any recurring issues with the approach or content?

Another question we're pondering is the unique value that the printed edition brings to the table. Much of the content in the PowerShell Cookbook was pre-published to this blog, newsgroups, or other channels. Many of the topics it addresses can be found through internet searches and forums. Many copies are floating around on Bit Torrent. Given all of that, why did you still purchase the printed version?

I know -- a lot of questions, very few answers! Let 'er rip.

Once in awhile, you need to do brain surgery on files locked by the system. This is a common problem run into by patches and hotfixes, so Windows has a special mechanism that lets it move files before any process has the chance to get its grubby little hands on it. This can only be done during a reboot, leading to the dire warning given to you by many installers.

The Win32 API that enables this is MoveFileEx. Calling this API with the MOVEFILE_DELAY_UNTIL_REBOOT flag tells Windows to move (or delete) your file at the next boot.

Here’s how to do it from PowerShell:

 

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024

function   Move-LockedFile {     param ( $path ,   $destination )     $path   = ( Resolve-Path   $path ) . Path     $destination   =   $executionContext . SessionState . Path . GetUnresolvedProviderPathFromPSPath( $destination )     $MOVEFILE_DELAY_UNTIL_REBOOT   =   0x00000004     $memberDefinition   =   @'     [DllImport("kernel32.dll", SetLastError=true, CharSet=CharSet.Auto)]     public static extern bool MoveFileEx(string lpExistingFileName, string lpNewFileName,        int dwFlags); '@     $type   =   Add-Type   -Name   MoveFileUtils   -MemberDefinition   $memberDefinition   -PassThru     $type :: MoveFileEx( $path ,   $destination ,   $MOVEFILE_DELAY_UNTIL_REBOOT ) } [C:\Windows\system32\config\txr] PS:181   >   dir   -force   |   % { Move-LockedFile   $_ . Name ( Join-Path   c:\temp\txr ( $_ . Name +   ".Bak" )) } [C:\Users\leeholm] PS:182   >   dir   -Filter   "NTUser.DAT{*"   -force   |   % { Move-LockedFile   $_ . Name ( Join-Path   c:\temp\txr ( $_ . Name +   ".Bak" )) }

I've long wondered exactly how few coins you need in your pocket in order to perfectly round out any bill. I usually grab a handful and hope it works out. Even that mathematically astute technique sometimes leaves me a nickel or few pennies short, though, so I settle for making change that gets me a quarter back instead of yet another handful of ore.

Even this settle-for-second-best option isn't that great. It can cause permanent damage to unsuspecting cashiers that aren't so good at math. Wondering why you would ever give them $1.13 for a $0.88 bill, they'll often just give you your change back AND then the stack of coins they were originally planning to load you up with.

Well, no longer.

It turns out that you need exactly 10 coins in your pocket: 3 quarters, 2 dimes, 1 nickel, and 4 pennies. With these in your arsenal, you can make perfect change for any bill.

How can you be sure? Brute force is your friend, as is PowerShell, of course.

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027

$coins   =   @{   0.25   =   0 ;   0.10   =   0 ;   0.05   =   0 ;   0.01   =   0   } function   SelectCoins ( [Decimal]   $change ) {     $result   =   $coins . Clone ( )     foreach ( $denomination   in   $coins . Keys   |   Sort   -Desc )     {         while ( $change   -ge   $denomination )         {             $change   -=   $denomination             $result [ $denomination ] ++         }     }         $result } $results   =   1 .. 99   |   %   {   SelectCoins   ( $_   /   100 )   } foreach ( $denomination   in   $coins . Keys   |   Sort   -Desc ) {     ( "{0:c}: "   -f   $denomination )   +         ( $results   |   %   {   $_ [ $denomination ]   }   |               Measure-Object   -Max ) . Maximum }

Gives:

$0.25: 3
$0.10: 2
$0.05: 1
$0.01: 4

Vladimir Averkin recently wrote a series of posts that show how to export code with syntax highlighting into HTML and RTF formats. It works great in Outlook, but was causing Windows Live Writer to crash. The reason is that the HTML stream of the clipboard isn’t just a blob of HTML – it’s supposed to be placed into the clipboard as CF_HTML. Investigation of that issue gave enough information to exactly pinpoint the crash in Live Writer, which they were quick to resolve once we pointed out. So it was a positive thing after all :)

While fixing the script, I took the opportunity to make the HTML prettier, work from both the ISE and the command-line, and fix a few bugs. I’ve posted it here: http://www.leeholmes.com/projects/scripts/Set-ClipboardScript.ps1.txt, as well as below.

We frequently get questions asking, “Where can I get a PowerShell script encoder so I can write secure scripts like the Visual Basic Script Encoder?”

The answer is that it is impossible to hide the password from the user if the script ever needs it. This is true of PowerShell, VBScript, C#, C++, Assembly, or any other language. There will always be some point when your script has reversed all of the encryption / protection mechanisms, giving the “attacker” complete access to it. If you don’t want the password itself hanging around in a script file, you can prompt the user for it. If the user is never supposed to know it, then you need to re-think your architecture.

Microsoft hasn’t been clear enough documenting what protections the Script Encoder offers, but here is an excerpt from the Scripting Guys:

Now, the important thing to keep in mind is that the script is simply encoded (or obfuscated); it is definitely not encrypted. What does that mean? That means the encoder will hide your script from most people; however, a truly determined hacker - armed with a knowledge of codes or armed with a utility downloaded from the Internet - could crack the code. Among other things, that means that you should never do something like “hide” an Administrator password in a script and assume that the Script Encoder will keep it safe from prying eyes. It won’t. It’s an encoder, not an encrypter, and there’s definitely a difference.

I’m not sure why the main download page is fond of the term “determined hacker” – a 30 second search for “vbe decryption” returns pages of results.

Now, a valid response to the whole situation is that you really only want to deter casual investigation, or that reversing the protection can then be linked to a breach of contract or software license. If you are in either of those boats, you don’t need an official tool to do this for you. Hiding your script behind Base64 encoding or ROT-13 should offer plenty of protection, and takes only a few lines of scripting. If you have the skill to make that decision, you have the skill to implement it as well.

A while back, Roberto Farah published a script library to help control WinDbg through PowerShell. I’ve been using WinDbg for more debugging lately, and decided (after following one to many object references by hand) that I needed to script my investigations.

PowerDbg is definitely helpful – Roberto has tons of great scripts published that help analyze all kinds of interesting data. It also made me think of an alternative approach that works around some of the problem areas – PowerDbg uses SendKeys, window focusing, and used WinDbg logging as the communication mechanism. After some investigation, I thought that automation of the command-line version (cdb.exe) through its input and output streams might be easier and more efficient – which indeed it was.

You set up a remote from the Windbg instance you want to control, and then the WinDbg module (below) connects to the remote session (by manipulating standard in / standard out of cdb.exe) to manage its output.

Windows PowerShell V2
Copyright (C) 2008 Microsoft Corporation. All rights reserved.
PS C:\Users\leeholm> Import-Module Windbg
PS C:\Users\leeholm> Connect-Windbg "tcp:Port=10456,Server=SERVER"
PS C:\Users\leeholm> Invoke-WindbgCommand .symfix
PS C:\Users\leeholm> Invoke-WindbgCommand .reload
0:009> Reloading current modules
................................................................
...........
PS C:\Users\leeholm> Invoke-WindbgCommand k
0:009> ChildEBP RetAddr
0460fbe8 76ebd0d0 ntdll!DbgBreakPoint [d:\foo.c @ 206]
0460fc18 76fc4911 ntdll!DbgUiRemoteBreakin+0x3c [d:\bar.c @ 298]
0460fc24 76e6e4b6 kernel32!BaseThreadInitThunk+0xe [d:\baz.c @ 66]
0460fc64 76e6e489 ntdll!__RtlUserThreadStart+0x23 [d:\bing.c @ 2740]
0460fc7c 00000000 ntdll!_RtlUserThreadStart+0x1b [d:\bing.c @ 2672]
PS C:\Users\leeholm>

Here’s an example function to demonstrate its use:

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054

################################################################################ ## ## Resolve-PsInvocationInfo.ps1 ## Resolves the command and script information from an active PowerShell ## process ## ################################################################################ Import-Module   windbg Connect-Windbg   "tcp:Port=10456,Server=SERVER" function   Resolve-Member ( $address ,   $member ) {     $output   =   Invoke-WindbgCommand   !dumpobj   $address         if ( -not   $member )     {         $output     }     else     {         $currentMember   =   ( $member   -split   "\." ) [ 0 ]         $remaining   =   $member . Remove ( 0 ,   $currentMember . Length ) . TrimStart ( '.' )                 Write-Verbose   "Looking for $currentMember on $address"                 $output   =   $output   |               Select-String   ( "(instance|shared).*$currentMember"   +   '$' )   |             Select-String   -NotMatch   00000000         if ( $output )         {             $columns   =   -split   $output             $address   =   $columns [ 6 ]                         Resolve-Member   $address   $remaining         }         else         {             Write-Error   "Could not resolve $currentMember on $address"         }     } } $null   =   Invoke-WindbgCommand   .loadby   sos   mscorwks $output   =   Invoke-WindbgCommand   ( "!dumpheap -type "   +     "System.Management.Automation.InvocationInfo -short" ) foreach ( $line   in   $output ) {     Resolve-Member   $line   commandInfo.name     Resolve-Member   $line   scriptToken._script     Resolve-Member   $line   scriptToken._line } Disconnect-Windbg

And the module itself (WinDbg.psm1, place in a “WinDbg” folder in your modules folder):

(Edit: 05/13/09 - Updated to support local kernel debugging)

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148

################################################################################ ## ## WinDbg.psm1 ## Automate WinDbg with PowerShell scripting ## ## To use: ## In WinDbg, set up a server: .server tcp:Port=10456 ## ## In PowerShell ## ## Import-Module windbg ## Connect-Windbg -remote "tcp:Port=10456,Server=<server>" ## Other remote connection strings / protocols work, too. ## ## For local kernel debugging: ## ## Import-Module Windbg -ArgumentList 'C:\<path>\kd.exe' ## Connect-Windbg -ArgumentList "-kl" ## Invoke-WindbgCommand "!process" ## ## Cleaning up: ## Disconnect-Windbg ## ################################################################################ param ( $cdbPath   =   "C:\Program Files\Debugging Tools for Windows\cdb.exe" ) $SCRIPT:windbgProcess   =   $null $SCRIPT:currentConnection   =   $null ## Connect to a windbg remote session function   Connect-Windbg {      param (          [ Parameter ( ParameterSetName   =   "Remote" ,   Mandatory   =   $true ) ]          $remote ,          [ Parameter ( ParameterSetName   =   "ArgumentList" ,   Mandatory   =   $true ) ]          $argumentList                   )               if ( $SCRIPT:currentConnection   -and   ( $SCRIPT:currentConnection   -ne   $remote ) )      {          throw   "Already connected to $remote. Use Disconnect-Windbg, "   +                "then connect to another instance."      }           ## Launch cdb.exe, the command-line version of WinDbg.      ## Take control of its input and output streams, which we'll use      ## to capture commands and their output.      if ( -not   $SCRIPT:currentConnection )      {          $processStartInfo   =   New-Object   System.Diagnostics.ProcessStartInfo          $processStartInfo . FileName   =   $cdbPath          $processStartInfo . WorkingDirectory   =   ( Get-Location ) . Path          if ( $remote )          {                  $processStartInfo . Arguments   =   "-remote $remote"          }          else          {                  $processStartInfo . Arguments   =   $argumentList          }                   $processStartInfo . UseShellExecute   =   $false          $processStartInfo . RedirectStandardInput   =   $true          $processStartInfo . RedirectStandardOutput   =   $true            $SCRIPT:windbgProcess   =                [System.Diagnostics.Process] :: Start ( $processStartInfo )          $SCRIPT:currentConnection   =   $remote          if ( -not   $SCRIPT:windbgProcess )          {              return          }                   ## Ignore the stuff that was in the session before we          ## connected          $null   =   Receive-WindbgOutput      } } ## Disconnect from the session function   Disconnect-Windbg {      if ( $SCRIPT:windbgProcess   -and   ( -not   $SCRIPT:windbgProcess . HasExited ) )      {          $SCRIPT:windbgProcess . StandardOutput . Close ( )          $SCRIPT:windbgProcess . StandardInput . Close ( )          $SCRIPT:windbgProcess . Kill ( )      }           $SCRIPT:currentConnection   =   $null      $SCRIPT:windbgProcess   =   $null } ## Invoke a command in the connected WinDbg session, and return ## its output function   Invoke-WindbgCommand {      if ( -not   $SCRIPT:windbgProcess )      {          throw   "Not connected. Use Connect-Windbg to connect to an "   +              "instance of WinDbg."      }           $SCRIPT:windbgProcess . StandardInput . WriteLine ( "$args" )      Receive-WindbgOutput } ## Retrieve pending output from the connected WinDbg session function   Receive-WindbgOutput {      ## Add a special tag so that we know the end of the command      ## response      $sent   =   "PSWINDBG_COMPLETE_{0:o}"   -f   [DateTime] :: Now               $SCRIPT:windbgProcess . StandardInput . WriteLine ( ".echo $sent" )           $received   =   New-Object   System.Text.StringBuilder      ## Wait for the response to end      while ( $received . ToString ( ) . IndexOf ( $sent )   -lt   0 )      {          $null   =   $SCRIPT:windbgProcess . StandardOutput . EndOfStream          while ( $SCRIPT:windbgProcess . StandardOutput . Peek ( )   -ge   0 )          {              $null   =   $received . Append (                  $SCRIPT:windbgProcess . StandardOutput . Read ( ) ,   1 )          }      }           ## Split it into lines, and return everything but the new      ## prompt, and the "end response" tag      $output   =   $received . ToString ( ) . Split ( "`r`n" )      if ( $output . Length   -gt   2 )      {          $output [ 0 .. ( $output . Length   -   3 ) ]      } } Export-ModuleMember   -Function   Connect-Windbg Export-ModuleMember   -Function   Disconnect-Windbg Export-ModuleMember   -Function   Invoke-WindbgCommand $MyInvocation . MyCommand . ScriptBlock . Module . OnRemove   =   {   Disconnect-Windbg   }