If you need to get a crashdump running Windows Vista you’ll look for DRWTSN32.EXE for ever and a day. Unfortunately, it’s in vain, Dr Watson died…

Nevertheless that app has been very important for collateral quality control.

Vista has increased the intricacy of everything a lot. In general Vista is not saving minidumps, but keeps account of every crash or error report. If an app is WER registrated a crashdump is stored as well - if it’s not no crashdump is at dumpfolder. Neither here nor there.

This is how it works on Vista (as fair as I could figure out):

• WER just makes a crashdump for WER signed apps respectively if the WER server requests a report
• To get a minidump the following regesty value has to be set:
  HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ (DWORD) create a key named “ForceQueue” and set it to 1.
• Dumps are getting stored in user directory C:\Users\TheUserName\AppData\Local\Temp and C:\ProgramData\Microsoft\Windows\WER\ReportQueue. File extension is *.mdmp.
• You can have an overview at Control Panel-> maintenance -> Problems & Solutions -> Check Problems

You also can find several instructions on the web howto install Dr Watson on Vista. There also seems to a tool called DrVista that might help you - which I didn’t try…

From time to time I have battles with Visual Basic Script, which I usually avoid using.

I wanted console output because the process I’m starting should be unattended, rather than clicking through a bunch of MsgBoxes.

Typically, one prints in VBscript using a Wscript.echo("Hello, world!") line or some variant thereof. If you do not invoke with a cscript hello-world.vbs, you get a GUI/pop-up MsgBox, which I wish to avoid. I just wanted something to go right to the command line for output, without putting cscript at the beginning.
Wscript.StdOut.WriteLine dies, of course, if not also invoked with a cscript.

For different reasons I didn’t want to permanently set my default scripting host to cscript, either.

Probably the best solution to solve that problem is a simple stub in the script that will be called when it starts, which detects how the script was started, and re-starts it explicitly using cscript.exe if needed. It makes use of the wscript.fullname property (which is the path to the running host executable, either c:\windows\system32\cscript.exe or wscript.exe). If the script is running as wscript.exe, it will simply re-launch the script using cscript.exe and exit.
This way, if the local machine has wscript as the default host, it will immediately launch, detect that it was launched via wscript, and re-launch itself using wshell.run as a cscript. The local host doesn’t need to be reconfigured for this to work.

'this is at the start of your script
CheckStartMode
 
' This is somewhere else in your script
Sub CheckStartMode
     ' Returns the running executable as upper case from the last \ symbol
     strStartExe = UCase( Mid( wscript.fullname, instrRev(wscript.fullname, "\") + 1 ) )
 
     If Not strStartExe = "CSCRIPT.EXE" Then
          ' This wasn't launched with cscript.exe, so relaunch using cscript.exe explicitly!
          ' wscript.scriptfullname is the full path to the actual script
 
          set           oSh = CreateObject("wscript.shell")
          oSh.Run "cscript.exe """ & wscript.scriptfullname & """"
          wscript.quit
 
     End If
End Sub

The only disadvantage of that solution is that it closes the console window it opens as soon as the script is finished. I went through all of the options for intWindowStyle in the Run method of the WshShell object and none of them kept the spawned console open for more than a flash. Maybe there’s a hack for it, too.

Every time I have occasion to look at the Windows command line documentation, I seem to discover something new. Admittedly this is because I don’t really look for new stuff all that often…

The year’s discovery for 2008 might be Pathping which is a Windows based command-line tool (for Windows cmd) used to provide information about the path data takes to its intended destination, network latency and network loss at intermediate hops between a source and destination.

It’s a TCP/IP based utility that can be used when looking for errors in network. It does this by sending echo requests via ICMP and analyzing the results. ICMP stands for Internet Control Message Protocol. ICMP is an extension to the Internet Protocol (IP - part of the TCP/IP protocol suite). ICMP supports packets containing error, control and informational messages.

Like tracert, pathping will discover the route IP traffic will currently take to from your machine to a particular target on the internet, and how long each hop takes. But while tracert just shows you three samples for the timing to each hop, pathping runs for a few minutes, and sends out a much larger number of packets - 100 per hop by default. It then displays the average performance and packet loss for each hop in the chain. Since timing and packet loss can vary quite widely, three samples often isn’t enough to characterise the quality of your connectivity, so pathping can give a better picture of network health between distant machines.

A sample output could be:

pathping -n server
 
Tracing route to server [10.1.1.5]
over a maximum of 30 hops:
  0  10.1.2.1
  1  10.1.1.1
  2  10.1.1.5
 
Computing statistics for 50 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           10.1.2.1
                                0/ 100 =  0%   |
  1   35ms     0/ 100 =  0%     0/ 100 =  0%  10.1.1.1
                               13/ 100 = 13%   |
  2   28ms    16/ 100 = 16%     3/ 100 =  3%  10.1.1.5
                                0/ 100 =  0%   |
 
Trace complete.

PathPing is supplied in Windows NT, Windows 2000, Windows 2003, Windows XP and Windows Vista.

Finally it’s nothing spectacular that can’t be archieved otherways but it will ease your work in some cases.

PWN to OWN challenge is over and the winner were awareded with a good deal of money and the laptop they cracked.

At 12:38pm local time, the team of Charlie Miller, Jake Honoroff, and Mark Daniel from Independent Security Evaluators have successfully compromised the Apple MacBook Air, winning the laptop and $10,000 from TippingPoint’s Zero Day Initiative. According to sources at the conference, Miller used an exploit against the Safari browser that ships standard with Mac OS X.

A security researcher on Friday exploited a critical bug in Adobe’s Flash Player to hack a notebook running Windows Vista Ultimate, the second machine to fall in this year’s “PWN To OWN” challenge.

The only unclaimed laptop by the contest’s end was a Sony Vaio running Ubuntu Linux.

What does this tell us? I think it’s not as easy as it looks…

I’m pretty sure that the Vista being cracked and not the Ubuntu had something to do with luck, it also could have been the way round. Cracking MacBook Air due a bug in Safari Browser we can assume that the usage of a browser that has a uncommon update system, like Safari has, is not recommented. When Safari 3.1 is not detected in a user’s machine, the updating software, by default, automatically selects the browser for installation.

The bug in Flash Player, which was accountable fot Vista’s downfall, had also been appearing in the Linux version. It kinda dependented on chance.

An interesting, but also alarming evolution is that operating system are becoming more and more secure which will lead attention of malware coders to individual software being installed on the target’s machine. It’s alarming because it reduces the advantage Linux or Mac users had have because in further time most viruses, exploits used bugs in Windows. Not just because Windows has sufficiant bugs also because of the wide speaded usage of Microsoft’s OS.

Hopefully in future dangerous exploits won’t be a thread for all operating systems because a product is affected that is being used on every operating system.

Just a short snipped I’d like to not forget about.

The maximal possible pathlength on Windows is, as you probably know, 255 chars. For that reason you can use the following:

Convert short path to long:

String s = Short2Long(@"D:\MYTEMP~1\RESOUR~1\sql.txt");
 
public static String Short2Long(String sShortPath) {
    StringBuilder sLongPath = new StringBuilder(255);
    GetLongPathName(sShortPath, sLongPath, sLongPath.Capacity);
    return sLongPath.ToString();
}

Vice versa:

String s = Long2Short(@"D:\My Temp\ResourseProvider\sql.txt");
 
public static String Long2Short(String sLongPath) {
    StringBuilder sShortPath = new StringBuilder(255);
    GetShortPathName(sLongPath, sShortPath, sShortPath.Capacity);
    return sShortPath.ToString();
}

Hope it might help you somewhere along the way

I just want to share some information, which to browse the web for everytime again may require some time that can be better used otherways if already posted here.

I found the informational balloon tips that appear on my task bar to be very informative - initially, but become very annoying over time.

I personally like having the icons appear on the task bar, but the balloons have become very annoying. To allow your icons to appear without the balloons, you can do the following.

These instructions are for Windows XP:

• Run the REGEDIT from the Start > Run dialog.
• Locate the following registry folder:
  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
• Create a DWORD value called “EnableBalloonTips“. The default value will be zero. Leave the value as zero.
• Reboot your computer for this change to take effect.

This will disable all balloon tips on your task bar.

For connection tool tips like the one on the screenshot there’s also another way to disable them:
Just uncheck the “Show icon in the notification area when connected” option in connection properties.