Software Sleuthing

Blog Migration

Josh Poley [MSFT] — Sat, 22 Oct 2011 15:04:41 GMT

For more flexibility in my posting options, I'm moving off of blogs.msdn.com. New posts can be found here.

Your Password is Too Secure

Josh Poley [MSFT] — Tue, 13 Sep 2011 15:27:00 GMT

For obvious reasons, Microsoft employees are asked to refrain from bashing other teams or products in their blog posts. But with the dismantling of the Money product line a couple years ago, I feel the statute of limitations has expired and I can share a useful lesson.

At one point, I changed the password for my bank, and then went in to update the corresponding password in Microsoft Money so I could continue to download statements. Unfortunately, upon entering the password, I was met with this error box.

Here is a product, which is charged with protecting my most important data, and it is telling me that it can't accept a password which any typical computer-savvy user would consider a normal "strong" password. After seeing this message, my brain stopped working. If anything, a product which deals with access to someone's money should favor the uber-paranoid side of the security fence. But here was a product that actually limits a password's complexity and forced users to a weak one.

I can understand reasonable limits on length as there may be storage or processing concerns (I've run into web sites where an eight-character password was too long, and no, that is not a reasonable limit). But if you are working on the password-processing feature of your software, gimping a password's strength is something that should be avoided at all costs.

As an aside, you can use this utility to help gauge whether or not your password is strong.

WinDbg / i386kd Primer

Josh Poley [MSFT] — Mon, 29 Aug 2011 18:59:29 GMT

A handful of people on my team are working with the Windows code base to ensure we don't break them with compiler changes, and since some of them were new to kernel debugging, I put together a rather quick introduction to windbg/i386kd. The slide deck can be found here.

Console output with a transparent background color

Josh Poley [MSFT] — Tue, 26 Jul 2011 15:02:44 GMT

In Windows land, if you want to print out colored text to a console, you will probably end up calling SetConsoleTextAttribute to set the desired color, then calling it again to restore the original settings. Unfortunately the documentation doesn't make it very clear how to change just the foreground color; which, in my experience, is a fairly common scenario. (You will still need to worry about clashing or unreadable text, but that is outside of the scope of this post.)

HANDLE consoleOut = GetStdHandle(STD_OUTPUT_HANDLE);

CONSOLE_SCREEN_BUFFER_INFO csbiInfo = {0};
GetConsoleScreenBufferInfo(consoleOut, &csbiInfo);

SetConsoleTextAttribute(consoleOut, FOREGROUND_INTENSITY | FOREGROUND_RED |
(csbiInfo.wAttributes & (0x00F0)));

printf("Foreground red, background unchanged\n");

// restore the original colors
SetConsoleTextAttribute(consoleOut, csbiInfo.wAttributes);

The magic part is where we OR in the original attributes with a bit mask of 0x00F0 which just keeps the BACKGROUND_* values intact. The un-obvious (and extremely useful) thing to note, is that the original background will be kept intact even if it can't be expressed in the provided 4 bits of information (i.e. the user has defined a custom color using a 24-bit RGB value).

How Testers Test versus How Users Use

Josh Poley [MSFT] — Mon, 11 Jul 2011 16:05:00 GMT

With the emphasis on SDETs and generic Engineering teams, I've seen a growing disparity in how products are being tested versus how users actually use a product. Because it is often very easy to crank out more test cases (especially ones which just iterate on existing tests), testers often lose focus of what is actually important to a customer.

When looking at your automation ask yourself these questions:

Are my tests focused on the functionality which users care the most about? Figure out what matters the most to users. If users spend 80% of their time in one area of your product, that is where 80% of your testing should be as well.
How much time (both development-time and execution-time) is invested in edge/corner cases versus actual user scenarios? A finely-tuned unit-test suite is a great thing to have, but is not a substitute for actually testing the software. It is just too easy to spend more time adding variations and more test cases that don't offer any additional benefit.
Does the automation correctly hit all the same code paths under the same environmental situations? If your automation is relying too heavily on internal hooks at lower levels, it might not be exercising the software the way a user will be. Any deviation will reduce the effectiveness of the tests.
Are test cases executing in a "pristine" state? Often tests are run on a clean system, after a fresh install, utilizing perfectly scripted steps over clean data. Users don't work like that. Run tests under a heavily loaded system. Intermix test scenarios to mimic the user moving chaotically through the software. Use real-world data sets. Then on top of all that, throw in some task-switches, network fluctuations, etc.

To make customers happy, you need a way to quantify how Customerized your tests are. If the "how testers test the product" circle fully overlaps the "how a customer uses the product" circle, then your tests are highly Customerized, and you will have a better chance at satisfying your customers.

Hex Conversion via a Batch File

Josh Poley [MSFT] — Wed, 29 Jun 2011 15:27:00 GMT

Occasionally, when something bad happens, an application will return an exception code (which is occasionally an NTSTATUS value). Unfortunately dumping out %ERRORLEVEL% can give you a negative value which makes looking up the error a little harder. Since I was in batch-land, I had the desire to take the value and print it out in a hex format, which drastically simplified my diagnosis efforts.

Below is some batch code which will take a two's-compliment value, and print it out as an unsigned hexadecimal value. The basic algorithm is not very difficult (see 'hexloop' below): take the "ones place" digit off (by mod 16) and stick it in the result, then divide the input down by 16 and repeat. The tricky part comes when we have a negative value and thus need to deal with unsigned values that go beyond the range of a positively signed 32-bit value.

To deal with this we first figure out how far past the MAX_INT value we are (stored in _offset). We then break the number into two parts so that we can operate on them in the positive side of a signed variable. Into each part, we then need to add in the equivalent (also broken apart) MAX_INT pieces. The first part (the first digit) is handled immediately; for the remaining digits, we just fall down into the normal processing loop. Note that we are using the ! syntax for variables inside the 'if' statement as that helps keep the processor from getting confused.

@echo off
setlocal
setlocal ENABLEDELAYEDEXPANSION

call :tohex %1
echo %_DECVAL% == 0x%_HEXVAL%

goto :eof

:tohex
    set _DECVAL=%1
    set _HEXVAL=
    set _VAL=%1
    if %1 LSS 0 (
        REM break the number into two parts so that we can output the
        REM full value within the bounds of a 32 bit signed value
        set /A _offset="-(-2147483647 - !_VAL!) + 2"
        set /A _VAL="!_offset! / 16 + 0x7FFFFFF"
        set /A _P="!_offset! %% 16 + 0xF"

        if !_P! GEQ 16 (
        set /A _VAL="!_VAL! + 1"
        set /A _P="!_P! %% 16"
        )
        if !_P! LEQ 9 set _HEXVAL=!_P!!_HEXVAL!
        if "!_P!" == "10" set _HEXVAL=A!_HEXVAL!
        if "!_P!" == "11" set _HEXVAL=B!_HEXVAL!
        if "!_P!" == "12" set _HEXVAL=C!_HEXVAL!
        if "!_P!" == "13" set _HEXVAL=D!_HEXVAL!
        if "!_P!" == "14" set _HEXVAL=E!_HEXVAL!
        if "!_P!" == "15" set _HEXVAL=F!_HEXVAL!
    )

    :hexloop
    set /A _P="%_VAL% %% 16"
    if %_P% LEQ 9 set _HEXVAL=%_P%%_HEXVAL%
    if "%_P%" == "10" set _HEXVAL=A%_HEXVAL%
    if "%_P%" == "11" set _HEXVAL=B%_HEXVAL%
    if "%_P%" == "12" set _HEXVAL=C%_HEXVAL%
    if "%_P%" == "13" set _HEXVAL=D%_HEXVAL%
    if "%_P%" == "14" set _HEXVAL=E%_HEXVAL%
    if "%_P%" == "15" set _HEXVAL=F%_HEXVAL%
    set /A _VAL="%_VAL% / 16"
    if "%_VAL%" == "0" goto :endloop
    goto :hexloop
    :endloop

    set _offset=
    set _P=
    set _VAL=
    goto :eof

Common Process Termination Values

Josh Poley [MSFT] — Mon, 13 Jun 2011 15:36:08 GMT

When your application does something the OS (or the application itself) doesn't like, often the floor gets yanked out and the process is terminated in an abrupt manner. If you don't happen to be running with a debugger, often the easiest way to get an idea of what went wrong is to look at the process exit code. Here we have an assortment of some of the more frequently encountered exit codes you are likely to witness:

0x00000003	CRT's abort() or assert() was called.
0x80000003	An unhandled breakpoint (such as __debugbreak()), may also be caused by /RTC run-time checks.
0xC0000005	Access violation.
0xC00000FD	Stack overflow. Avoid recursion, move large stack buffers onto the heap, or increase the stack size via the /STACK linker option.
0xC0000135	A required DLL was not found. Make sure you deploy all necessary components.
0xC0000138	An API is missing from the loaded DLL (searched by ordinal). This, and the one below, is typically due to running on an older version of Windows. You can change your _WIN32_WINNT, _WIN32_IE, etc. defines to target a previous version, or use LoadLibrary/GetProcAddress on the specific new API.
0xC0000139	An API is missing from the loaded DLL (searched by name).
0xC0000142	DllMain (from a required library) returned FALSE.
0xC0000374	Heap corruption detected (via HeapSetInformation's HeapEnableTerminationOnCorruption option).
0xC0000409	Stack corruption detected (typically a result of /GS stack checks).
0xC0000417	Invalid CRT parameter (typically a result of the safe CRT functions failing a check).

The 0xC… values are NTSTATUS codes, so if you happen to see other values in that range you know where to look them up.

Batch File String Substitution with Nested Environment Variables

Josh Poley [MSFT] — Fri, 03 Jun 2011 15:10:31 GMT

The SET command has some nice extensions that let you do various manipulation operations on environment variables. One said operation is the string substitution feature, which is often used to perform basic pattern replacements such as stripping out quotes around filenames:

set ABC="c:\foo.txt"
set ABC=%ABC:"=%
echo %ABC%

In the above sample, the quotes around the filename are removed (the search pattern is located between the colon and the equal sign, and the replacement pattern is located after the equal and before the ending percent sign – which is empty in this case).

I recently had a need to replace the beginning portion of a path name, with a different directory. But, unfortunately, I wasn't able to use hard-coded pattern strings as the both the initial directory and the replacement were unknown beforehand. This meant that I was left with the unfortunate task of trying to use an environment variable inside of the replacement syntax. Needless to say, nesting % signs didn't go very well for me.

Luckily, there is a mode of cmd.exe which support delayed environment evaluation, and offers a new syntax for evaluating the environment variable.

cmd.exe /v

When /v is passed into cmd.exe, it allows you to expand environment variables using ! instead of %:

echo !ABC!

Using both forms of expansion, I can nest one inside of the other, allowing me to use a variable for both the search string as well as the replacement:

set TARGETPATH=!TARGETPATH:%ROOT%=%NEWROOT%!

As an aside, here is a little test which will let you determine if /v is enabled or not:

set _EXP=expanded
if "!_EXP!" NEQ "expanded" echo ERROR: You must start cmd.exe with /v & goto :eof
set _EXP=

Limits of OLEDB and Access Passwords

Josh Poley [MSFT] — Wed, 25 May 2011 15:49:00 GMT

People that know me know I hate useless error codes. During code reviews if I see someone attempting to return E_FAIL I will often launch into a blistering remark about how they are being lazy and making other developer's lifes harder all at the same time. The problem with E_FAIL is that it is completely unactionable; it gives the caller (or the end user) zero details about what failed or how to fix it.

Given this, you can imagine the distaste in my mouth when I encountered a DB_E_ERRORSOCCURRED (0x80040E21) error while just trying to open an Access database using OLE (via CDataSource/CSession). I get this error back with no fanfare about what the actual problem is. The connection string used looked something like this:

PROVIDER=Microsoft.ACE.OLEDB.12.0;DATA SOURCE=database.accdb;Jet OLEDB:Database Password=' O1i6PidNWwKFHhl6DWJa7UZjD8RiPZ'

After blindly fishing around, I narrowed it down to the actual password that was the issue. If I disable the password protection on the database, I could connect just fine.

After hacking around some more I discovered that it is the length of the password (and not the any specific characters) which cause the open operation to fail. My life could have been so much happier if I had received a specific error message, or even an overloaded one which would help point to the length of the password as an issue. Looking through the standard windows headers, there are a handful of existing errors that would have been much nicer to see than an "errors occurred" message.

So, if you happen to run into this error code yourself, you may need to shorten the password to fewer than 20 characters.

The Many Faces of Visual C++

Josh Poley [MSFT] — Tue, 15 Dec 2009 17:21:00 GMT

Microsoft has an uncanny ability to confuse and befuddle users with the ever changing names of products across versions. Visual C++ is no stranger to this concept and I'm often left with trying to interpret some innocuous sounding statement into something meaningful to my simple mind.

You need to link with the VC8's libs.

Ok, great, now what does that mean? Is that version 8.0 (as reported by the binary)? Is it "Visual C++ 2008"? One could go mad trying to understand that each version has three different ways to identify and name it. To simplify my own life, I've created a chart with the last handful of versions and their equivalent names, hopefully this will be useful to others as well.

Product Name	Product Version	Compiler File Version
Visual C++ 2010	VC10	16.xx
Visual C++ 2008	VC9	15.xx
Visual C++ 2005	VC8	14.xx
Visual C++ .NET 2003	VC7.1	13.10
Visual C++ .NET 2002	VC7.0	13.00
Visual C++ 6.0	VC6	12.xx

Magic Numbers: Integers

Josh Poley [MSFT] — Fri, 09 Oct 2009 20:37:00 GMT

After many moons of sitting in a queue somewhere, the MSDN Tester Center just posted my intro article on special numbers you probably want to think about when running tests. The paper addresses several interesting domains of integers (all the way up to 64-bits) and gives you samples of important values to use:

In testing software, we often miss an entire class of bugs just because we don't happen to think about one category of inputs and how they might adversely affect the system. To help combat this in with my own tests, I've pulled together a listing of numbers which are good to use in testing for various independent reasons.

http://msdn.microsoft.com/en-us/library/ee621251.aspx

Test Plan Template

Josh Poley [MSFT] — Fri, 02 Oct 2009 20:51:00 GMT

While looking at some of the traffic statistics for the MSDN Tester Center, I noticed that a bunch of people arrived at the site as a result of doing a Google search for "test plan template". The primary starting point for a template is really the IEEE standard 829-2008 which breaks apart the various types of documents and goes into detail on what should be present in each. In the Xbox software organization, we've taken the Level Test Plan and tweaked it to better fit our needs, but a (generalized) version of it is posted for your viewing pleasure: Word Template (dotx) or PDF.

The Brute Tester

Josh Poley [MSFT] — Mon, 01 Jun 2009 20:47:00 GMT

A co-worker of mine was working on a tool to watch our release share for the appearance of a test result file, for which he would then publish up to a TFS server. The "trx" results file in question is actually being created on the Xbox console by our custom test harness, and historically was around a 10 megabyte (Unicode) file for a typical daily regression run. Yet on a Friday afternoon (when it actually happened to be nice outside), I get the following email from the tool writer:

Any idea why daily\testResults.trx is 1.10GB? It’s too large to load and publish.

I'm thinking to myself: "One gig? Ay corumba! Did something go into a bad loop or something?"

I go out to the release server and start digging through the various log files, and sure enough, that thing is huge. Luckily we also produce a little rollup by component area which is written out to a text file and only contains the totals. The previous day's totals came out to 6422 tests for this suite. Today's number: an unorthodox 454,216. Yea, I guess adding 447,794 test cases will definitely blow out the size of a TRX file.

Now to dig a little deeper. The four hundred and forty-seven thousand test cases were just in one feature area. Looking at the test code it was definitely following a brute-force pattern over multiple axis, the first instance I noticed was O(n³).

Cranking through half-a-million test cases for a single feature is probably not the best use of your time (or the computer's). And I would hate to be a developer asked to run this suite in order to isolate a failure down deep in a nest of loops ("sorry Joe Developer, but it starts to fail around the 300,000th test case, good luck with that breakpoint"). Instead you should be trying to pick the fewest (reasonable) cases that adequately test the component. Here are some ideas to get you started:

· Use Equivalence Classes/Partitioning. You can even use Code Coverage to help determine groups.

· Use All-Pairs or Pairwise pruning techniques (Microsoft's PICT tool can be downloaded for free).

· Use data generation (e.g. Fuzzing) or Data-driven techniques to increase your coverage over time. You don't need to run every single variation all at once, instead you increase your surface area a little bit each day.

Crashed Conference Room (ɯooɹ)

Josh Poley [MSFT] — Thu, 21 May 2009 17:27:00 GMT

So we have these fancy touch screen displays on the outside of our conference rooms which will tell us when the room is booked (and by whom). They are definitely handy as they help resolve the inevitable conflict when multiple groups arrive at the same time and then fight over who owns the room. They also have the added bonus of allowing an individual to walk-up and immediately reserve an available conference room using the touch screen interface.

This is all assuming, of course, that the device hasn't crashed. In the past several weeks that our team has been in the new buildings I've now seen two conference rooms who's displays have crashed (on this floor alone).

And yes, not only do they crash with a splendid Blue-Screen-Of-Death, but they crash upside down.

The only reason I could think of for inverting the normal, run-time image, would be if you could access the unit from the back: if you flipped the screen down in a diagnostics mode, then everything would be right-side-up. Unfortunately these units aren't accessible from the back. They are truly embedded in the wall.

As I see it, there are two failures here. One is obviously in the uptime testing/certification of the devices. These things are on and running 24x7x365 and apparently something got missed. The second failure is a design issue. There is no user means of resetting the device. Every time these things crash, a technician has to come out, crack open the front panel and reboot the hardware.

Upcoming Testing Conferences (2nd half of 2009)

Josh Poley [MSFT] — Wed, 13 May 2009 20:20:00 GMT

Here is my semiannual post on testing conferences that will be occurring later this year.

CAST	July 13 - July 16	Colorado Springs, Colorado, USA
ISSTA	July 19 - July 23	Chicago, Illinois, USA
softec	July 20 - July 22	Kuala Lumpur, Malaysia
STANZ	August 24 - August 25	Wellington, New Zealand
STANZ	August 27 - August 28	Sydney, Australia
Practical Software Quality and Testing	September 14 - September 18	Minneapolis, Minnesota, USA
SSQC	September 15	Zurich, Switzerland
CONQUEST	September 16 - September 16	Nuremberg, Germany
SSQC	September 24 - September 25	Stockholm, Sweden
SSQC	October 5	London, England
StarWest	October 5 - October 9	Anaheim, California, USA
QA&TEST	October 21 - October 23	Bilbao, Spain
Pacific NW Software Quality Conference	October 26 - October 28	Portland, Oregon, USA
expo:QA	October 27 - October 29	Madrid, Spain
SSQC	October 28 - October 29	Melbourne, Australia
Great Lakes Software Excellence Conference	November 16 - November 17	Grand Rapids, Michigan, USA
EuroStar	November 30 - December 3	Stockholm, Sweden

Finding Database Connection Strings

Josh Poley [MSFT] — Thu, 07 May 2009 19:04:00 GMT

For a simple tool I was working on I needed to talk to a Microsoft Access database from my program. Now, most of the database work I've done in the past has been against SQL Server, so I needed to dig up the magic voodoo which represents the "connection string" for Access 2007 files. The connection string is used to tell the engine underlying the APIs how to talk to a specific type of database or file (i.e. what driver to use). Unfortunately most of the samples I found in MSDN were for an older version of Access (dealing with the old .mdb files) and not for 2007's .accdb files.

After consulting my good friend Google, I stumbled across the "Connection String" site which gave me exactly what I needed and I figured was useful enough to share.

Communication is Optional

Josh Poley [MSFT] — Wed, 15 Apr 2009 00:41:00 GMT

Clear communication is essential to our jobs and yet it always amazes me how poorly we do it. I received this chart in an email (about stress results).

Now, the interesting part: I've just given you as much context as to the meaning of the chart (and the email) as the author did. From the legend, I now know what color green, yellow, and red are, but aside from that, I've learned absolutely nothing. I may be able to go away with a little bit of comfort since the "red" line has gone down (and hopefully that is a good thing), but otherwise this email has done nothing but waste my time (especially since I've emerged from my blogging hiatus to write about it).

When you communicate with someone, you are hopefully trying to deliver some kind of message. If that message isn't brutally clear, then you have failed. In the case of the stress email, what was missing was a substantial amount of context. But even if you had been privy to the dark mysteries which made up that missing information, you would still have had to do your own analysis and basically connect the dots between what a "green" line is and what it actually represents, because that link itself was not brutally obvious to begin with.

If you are going to take the time to deliver a message, then take the time to actually think about what you are saying and how you are saying it. If the author had actually thought about the chart for a second he probably would have realized that units would be a good thing and the default/existing legend was completely useless.

Top 25 software errors

Josh Poley [MSFT] — Mon, 12 Jan 2009 19:41:00 GMT

SANS, along with a coalition of individuals and software organizations, just released their list of top "25 most dangerous programming errors". There has been some talk of making these a "requirement" or some sort of logo program to help protect customers when deciding which software to use or purchase.

From a developer's perspective you should review these and ensure your design and code are doing the right thing. From a tester's perspective, be sure you have cases in place to validate and document how you are verifying these. If the items do become a hard requirement your group will probably have to provide proof of what was tested and how.

Ideally your team is doing all this anyway, but if not, here is a handy checklist to get started.

New Black Book

Josh Poley [MSFT] — Wed, 07 Jan 2009 21:22:00 GMT

Before the holidays, there was a big re-organization of personnel here in Xbox land. As a result, I figured that this would be a good time to update my Black Book and have some more copies printed out for all the folks which are now a part of our new-and-improved software testing family.

The version which Bj just recently blogged about here was last updated a year ago, so the new one obviously contains more content. The changes also include formatting for better printing out in a 5.5" x 8.5" booklet (if you are so inclined). And as an aside, I'm not sure I deserve space in the same blog as the likes of Binder etc, but I will take what I can get :)

Link to PDF: Black Book

For those of you which haven't seen it yet, it just contains a plethora of random reference material. The likes of which I have no desire to memorize, but for some reason I find myself having look up more than once. At least having it all in one place means I no longer have to spend time searching.

MiniDumps and "Bad" Stacks

Josh Poley [MSFT] — Mon, 10 Nov 2008 19:07:00 GMT

A fellow reader sent a comment outlining the following problem:

I'm using the DMPSTK example from the Debugging Tools SDK. If I generate a crash dump from within Visual Studio 2005, I can see the call stack perfectly. However, if I create my own crash dump (the same as you do in your blog), I get several LoadLibrary(ext), LoadLibrary(exts), ... failures. What's more important to notice is that the callstacks are different.

The LoadLibrary messages are benign and just an artifact of the debugger attempting to load additional plug-ins. But with regard to the stack traces, things get more interesting.

It turns out that the crash dump files created with Visual Studio are slightly different from the ones created via the API MiniDumpWriteDump. On top of that, WinDBG and the debugging engine exposed by WinDBG handle things a little bit differently with regard these dumps. The main difference stems from the use of embedded "contexts". A context contains the basic state of the system (CPU registers for example), and crash dumps can contain an embedded context which gets added in if you pass down the appropriate exception details to MiniDumpWriteDump.

If you were to load up one of these API generated crash dump files in WinDBG itself, the program will kindly tell you that there is an additional context and in order to use it, you need to issue the ".ecxr" command. Until you do this, the stack trace you will see possibly is not the stack you are interested in. This is where things are going wrong for our reader, who was displaying the default stack via the code in DMPSTK sample.

Luckily for us, we can do the equivalent to .ecxr in our code allowing us to get the "correct" stack.

To start with we replace IDebugControl for IDebugControl4. This then gives us access to the GetStoredEventInformation and GetContextStackTrace methods.

If we were to modify the initial code from this blog entry, we would end up with something like this which lets us try to get the embedded context, otherwise just fall back on the old standby (GetStackTrace).

HRESULT DumpStack(IDebugControl4 *control, IDebugSymbols *symbols)

{

#define MAX_FRAMES 1024

HRESULT hr = S_OK;

DEBUG_STACK_FRAME stackFrames[MAX_FRAMES] = {0};

ULONG numFrames = 0;

char context[1024] = {0};

ULONG type = 0;

ULONG procID = 0;

ULONG threadID = 0;

ULONG contextSize = 0;

char *contextData = NULL;

// look for an embedded event

hr = control->GetStoredEventInformation(&type, &procID, &threadID,

context, sizeof(context), &contextSize, NULL, 0, 0);

// get the stack trace

if(SUCCEEDED(hr))

{

contextData = new char[MAX_FRAMES*contextSize];

hr = control->GetContextStackTrace(context, contextSize,

stackFrames, ARRAYSIZE(stackFrames), contextData,

MAX_FRAMES*contextSize, contextSize, &numFrames);

}

else

{

hr = control->GetStackTrace(0, 0, 0, stackFrames,

ARRAYSIZE(stackFrames), &numFrames);

}

...

Just don't forget to delete the newly allocated "contextData" buffer at the end of the function.

Upcoming Testing Conferences (1st half of 2009)

Josh Poley [MSFT] — Tue, 04 Nov 2008 19:56:00 GMT

Here are the links and dates for some of the testing related conferences which are approaching.

Future Test	February 24 - February 25	New York, New York, USA
Swiss Testing Day	March 18	Zürich, Switzerland
ANZTB	March 23 - March 25	Sydney, Australia
SEPG	March 23 - March 26	San Jose, California, USA
STP	March 31 - April 2	San Mateo, California, USA
ICST	April 1 - April 4	Denver, Colorado, USA
QUEST	April 20 - April 24	Chicago, Illinois, USA
CITCON NA	April 24 - April 25	Minneapolis-St. Paul, Minnesota, USA
ITNG	April 27 - April 29	Las Vegas, Nevada, USA
PSQT	April 27 - May 1	Las Vega, Nevada, USA
StarEast	May 4 - May 8	Orlando, Florida, USA
ICEIS	May 6 - May 10	Milan, Italy
CITCON ANZ	June	Brisbane, Australia
Better Software	June 8 - June 11	Las Vegas, Nevada, USA
CAST	July 13 - July 16	Colorado Springs, Colorado, USA
ISSTA	July 19 - July 23	Chicago, Illinois, USA

If you want to get a jump start on conferences in the latter half of 2009, you can browse through the ones that were around in 2008. And thanks to Alan's comment on that page, I'm now pushing these through the Tester Center site as well, so they should be showing up there in the near future.

New Xbox Experience

Josh Poley [MSFT] — Mon, 03 Nov 2008 19:33:00 GMT

This blog has been pretty quiet for a while since we've been busy doing the last push getting the "New Xbox Experience" polished and ready for release later this month. The new UI is pretty cool and is a nice break from the "Blade" interface which I've always thought was too web'ish (and very flat coming from the green 3D space on the original Xbox).

As for functionality, I'm the most excited about the Netflix integration and the ability to install games to the hard drive. Both of these features have been written about elsewhere, so there isn't much need to go into detail here. But they will definitely improve the entertainment and gaming enjoyment people experience from their Xbox console.

And since the whole "Avatars" thing is a big topic as well, here is an Xbox rendition of myself.

Off to StarWest

Josh Poley [MSFT] — Mon, 29 Sep 2008 18:13:00 GMT

I'm off at StarWest, so the blog will be a bit quieter this week. If you happen to be in Anaheim, look for the pale bald guy.

Save My Image File's Metadata

Josh Poley [MSFT] — Thu, 25 Sep 2008 18:03:00 GMT

The relatively new "Metadata Working Group" just released their first publication on guidelines for making the metadata stored in image files more portable across applications and file formats. Ever since I started photographing with a Digital SLR camera, I've been paranoid about preserving the rich metadata stored in every file. Paranoid to the point of writing my own tool for modifying/adding to the information as pretty much every single application I've ever tried has corrupted the information to some extent (deleting tags, moving them around, and generally doing bad things).

The goals of the working group are admirable, now we just need more applications to start following them.

Running 32bit dependent scripts in a 64bit world

Josh Poley [MSFT] — Thu, 18 Sep 2008 20:44:00 GMT

As seen earlier, it can be problematic to run scripts which rely on 32bit COM objects on a 64bit platform. To make things easier, I wrote basic some script code to detect that the wrong scripting host was run and fork out to the correct one. This just uses a variation of the "detect cscript vs. wscript" pattern, but instead we look at the current processor and do a check to see if we are running the wrong flavor of the script host.

// this script code relies on 32bit COM objects, if we are running on

// a 64bit system we will want to run under WOW64 (the x86 emulator).

var shell = WScript.CreateObject("WScript.Shell");

var cpu = shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%").toLowerCase();

var host = WScript.FullName.toLowerCase();

// check to see if we are on an AMD64 processor and running the

// wrong version of the scripting host.

if(host.indexOf("system32") != -1 && cpu == "amd64")

{

var syswow64Host = host.replace(/system32/g, "syswow64");

var newCmd = syswow64Host + " \"" +

WScript.ScriptFullName + "\" //Nologo";

// ATTEMPT to pass all the same command

// line args to the new process

var args = WScript.Arguments;

for(i=0; i<args.length; i++)

newCmd += " " + args(i);

WScript.Echo("Running the syswow64 bit version instead...\n " +

newCmd + "\n");

// launch the new script and echo all the output

var exec = shell.Exec(newCmd);

while(exec.Status == 0)

{

if(!exec.StdOut.AtEndOfStream)

WScript.Echo(exec.StdOut.ReadAll());

WScript.Sleep(100);

}

if(!exec.StdOut.AtEndOfStream)

WScript.Echo(exec.StdOut.ReadAll());

WScript.Quit(exec.ExitCode);

}

// the real script code goes here ...

WScript.Echo("done");

In this sample we are just checking for AMD64, so you may want to add logic for Itanium or other platforms as well.

Be sure to notice the "ATTEMPT" comment when transposing the command line options from the current process into the new one. The way that the command shell handles double quotes makes it hard to reproduce the exact command line from the support we have in script. For example, if you pass /abc="hello world" as an argument, the quotes will get stripped out and you will actually see /abc=hello world from your script code. If we pass this raw argument (as shown above) into the new process then the one argument will be interpreted as two because of the missing quotes. It is left as a reader exercise to detect spaces and reconstruct the exact arguments if needed.