A standalone redistributable installation before, Debugging Tools for Windows was finally absorbed into Windows SDK. MSDN quote from Download and Install Debugging Tools for Windows:

Install Debugging Tools for Windows as a Standalone Component

If you do not want an entire kit (WDK or SDK), you can install the Debugging Tools as a standalone component from the Windows SDK.

TO INTSTALL JUST DEBUGGING TOOLS: In the SDK installation wizard, select Debugging Tools, and clear other components that you don’t want. Note that .NET Framework 4.0 also will be installed.

• Install Debugging Tools for Windows as a Standalone Component

Install Debugging Tools for Windows without Installing .NET Framework

If you do NOT want to install the .NET Framework, there are additional steps needed.

Start the install process on a different computer where it is okay to install the .NET Framework. The installer requires .NET Framework 4.0 or higher, and will install .NET if it is not already installed.

Install the Debugging Tools as a standalone component from the Windows SDK. In the installation wizard, select Debugging Tools, and clear other components that you don’t want.

After installation is complete, go to the program files directory and look for (%Program Files%)\Windows Kits\8.0\Debuggers\Redist.
Copy and run the applicable MSIs on the computer that cannot have .NET.

Also, Windows SDK for Windows 8 Consumer Preview is not available as ISO download. So you have to use web downloader, install the gear, and having gone through this, the .MSI of interest are finally there.

You gotta be kidding me, though still thanks for not removing those completely.

The small application is a goos sample and useful tool in the same time. It enumerates PE binary resources and counts languages used. Why? Normally you want single language of resources, however Visual Studio IDE does not show you languages in a convenient way and it is so easy to make a language mess which does not bite you immediately but might bring you troubles later. Apart from this there was a suspicion that language mess might cause runtime bugs on UpdateResource API.

The application gets you a summary of languages used and returns with exit code (checkable using e.g. errorlevel) indicating number of languages.

Output is TSV: LANGID, Language Name, Resource Count:

C:\>ListResourceLanguages.exe C:\Windows\syswow64\shell32.dll
1049    Russian 545
1033    English 3318

Download links:

• Visual C++ .NET 2010 source code: Trac, Subversion

This update for Resource Tools adds an option to access custom resource types, such as FILE, TYPELIB, REGISTRY etc. It lets enumerate the resource, and load/save them. The COM interafce adds new Items property; the code snippet below accesses type library of image2.dll and saves it into external tyle library file image2.tlb:

image = new ActiveXObject("AlaxInfo.ResourceTools.Image");
image.Initialize("C:\\Windows\\syswow64\\imapi2.dll");
image.Items("TYPELIB").Item(1).SaveToFile(null, "imapi2.tlb");

Additionally, image.EndUpdate(false) call makes the object close all references to the underlying file so that it can be available for other operations (e.g. overwrite), and the COM object might be further re-initialized and reused.

Download links:

• Title: Alax.Info Resource Tools
• Version: 1.0.7
• Download (32-bit, Win32): ResourceToolsSetup.msi
• Download (64-bit, x64): ResourceToolsSetup-x64.msi
• License: This software is free to use

One of the nasty issues with LogProcessExceptions utility was that it was unable to attach to service processes and track them to catch their exceptions.

The actual problem was that the processes were not listed in first place, so there was nothing to attach to. Access and security requirements necessary for a process to debug another process are listed in MSDN DebugActiveProcess article:

The debugger must have appropriate access to the target process, and it must be able to open the process for PROCESS_ALL_ACCESS. DebugActiveProcess can fail if the target process is created with a security descriptor that grants the debugger anything less than full access. If the debugging process has the SE_DEBUG_NAME privilege granted and enabled, it can debug any process.

The utility did enable the SE_DEBUG_NAME privilege, however it was doing it prior to starting debugging session and after the process of interest was already pointed to by user.

This was insufficient because EnumProcesses only lists service processes (not actually exactly services, but processes running in different security context) in case debug privilege is already enable by the time of the API call. The utility now enabled the privilege well in advance and list the services, so can be effectively applied to those.

Download links:

• Partial Visual C++ .NET 2010 source code: Trac, Subversion
• Binaries: Win32 – LogProcessExceptions.exe, x64 – LogProcessExceptions.exe

Here go the updates on the COM library which offers easy to use COM interface to send emails, including over secure TLS and SSL channels:

• x64 build
• Attachments property to enable attchments to the message being sent
• ContentType property to enable text/html bodies
• subject non-English characters are correctly UTF-8 encoded
• empty To, CC, BCC fields are discarded
• recent properties are put onto persistence map: SecureSocketsLayer, TransportLayerSecurity, ContentType

message = new ActiveXObject("AlaxInfo.EmailTools.Message");
message.ServerHost = "smtp.gmail.com";

// ...
message.Body = "See attached."

attachment = message.Attachments.Add();
attachment.Type = "text/html";
attachment.Disposition = "attachment";
attachment.Name = "AutoBuildResults.html";
attachment.LoadFromFile("C:\\AutoBuildResults.html");

attachment = message.Attachments.Add();
attachment.Type = "image/jpeg";
//attachment.Disposition = "inline";
attachment.Name = "picture.jpg";
attachment.LoadFromFile("C:\\me.jpg");

// ...
message.Send();

Download Information

• Download (32-bit): EmailTools.dll
• Download (64-bit): EmailTools.dll
• License: This software is free to use

As a part of American Kestrel Partnership project, Peregrine Fund put live cameras online to broadcast interior and exterior views of American Kestrel nest boxes in their campus in Boise, Idaho.

One of the nestboxes is not only populated, four eggs have been laid recently and hatching is expected soon. The live picture is made possible by putting IP cameras and connecting them with to Ustream.tv broadcasting service through Adobe FMLE software through my IP Video Source DirectShow driver for IP cameras (the IP camera video feed is streamed 24/7 through a virtual video device picked up by FMLE and re-encoded into uploadable stream forwarded to Ustream online service for further distribution).

For more information, see:

• American Kestrel Website
• News Release: The Peregrine Fund launches new project, website to conserve American Kestrels
• NPR news story about the project
• American Kestrel Partnership Project
• American Kestrel on Wikipedia
• The Peregrine Fund on Ustream.tv

Watch the pet on live cameras below:

North Nestbox – Outside

http://ustre.am/Evbs

Live stream videos at Ustream

North Nestbox – Inside

http://ustre.am/J6jD

Live broadcasting by Ustream

South Nestbox – Outside

http://ustre.am/JjP2

Streaming Live by Ustream

South Nestbox – Inside

http://ustre.am/JjP7

Streaming Live by Ustream

The original intent is pretty clear, as MSDN states:

In release builds, ATLTRACE2 compiles to (void) 0.

As simple as this, but once in a while you are in a situation where release build fails to work for unknown reason and you need additional information for troubleshooting, and then you remember that you had debug tracing code still nicely available in the source, it is just being stripped out by definition of ATLTRACE/ATLTRACE2 macros for release builds.

To avoid reinvention of the wheel and putting new tracing, it might make sense to just re-enable existing tracing (certainly, if putting debug build binary is out of question, which might be the case in production environment and/or to avoid the hassle of installing additional runtime).

The macros need to be #undef’ined and redefined appropriately with or without limiting scope by push_macro/pop_macro #pragma’s. The trick with macro has to reach two goals, to pick file name, line and current symbol name using __FILE__ and friend macros, and also accept variable number of arguments.

The trick ATL does and we can use too is to define a helper class, with constructor taking file name, line and symbol name values, and cast operator () taking actual tracing parameters and arguments. Internally the output can be mapped to OutputDebugString API so that output could be seen using external tool such as DebugView.

When everything is well set, new the macros in question can be defined as follows:

#pragma push_macro("ATLTRACE")
#pragma push_macro("ATLTRACE2")

#undef ATLTRACE
#undef ATLTRACE2

#define ATLTRACE2 CAtlTrace(__FILE__, __LINE__, __FUNCTION__)
#define ATLTRACE ATLTRACE2

int _tmain(int argc, _TCHAR* argv[])
{
    ATLTRACE("First: %d\n", __LINE__);
    ATLTRACE(L"Second: %d\n", __LINE__);
    ATLTRACE2(atlTraceGeneral, 2, "Third: %d\n", __LINE__);
    ATLTRACE2(atlTraceGeneral, 2, L"Fourth: %d\n", __LINE__);
    return 0;
}

#pragma pop_macro("ATLTRACE2")
#pragma pop_macro("ATLTRACE")

And the Release configuration output will be:

Visual C++ .NET 2010 source code is available from SVN; in particular CAtlTrace class is here.

Bonus reading:

• Debugging and Error Reporting Macros
• Debugging with Visual Studio 2005/2008: Logging and Tracing

Direct3D based DirectShow video renderers – Video Mixing Renderer 9 and Enhanced Video Renderer – have been notoriously known for consuming resources in a way that you can run at most X simultaneously. There has been no comment published on the topic and questions (e.g. like this: How many VMR 9 can a PC support concurrently) remain unanswered for a long time. Video Mixing Renderer 7 was a good alternative for some time in past until it was cut down to be unable to support hardware scaling (thanks Microsoft!).

The trendy way to render video nowadays is using Enhanced Video Renderer, a Media Foundation subsystem with an interface into DirectShow to take over state of the art video rendering capabilities. So, how many EVRs one can run simultaneously? Chances are that it is less than one could suppose.

The interesting part is that there is no obvious evidence on type of resource running out, which causing next EVR instance to fail to run. And not even run, the failure seem to be coming up at an earlier stage of just connecting pins in stopped state. The failure might be accompanied with errors like E_INVALIDARG, ERROR_FILE_NOT_FOUND, E_UNEXPECTED. The actual limit appear to be loosely correlating to parameters of video output, such as resolution and bitness.

Desperately waiting for clarification, I am sharing the tool to estimate the limit:

• multiple EVR instances at once, hosted by multiple windows, which can be distributed across multiple monitors
• choices of resolutions and formats
• a double click on an individual renderer pops up property page set displaying effective frame rate
• 32- and 64-bit versions

A binary [Win32, x64] and partial Visual C++ .NET 2010 partial source code are available from SVN.

More and more applications hit the Windows limit of available address space for 32-bit applications, and the whole concept becomes more important for understanding due to necessity to work things around.

A thing, which is more or less easy to understand, is that a user mode 32-bit application can address 2^32 addresses. The addresses are not directly physical RAM and the operating system is responsible for management of the mapping addresses into RAM as a part of virtual memory manager operation. Paged memory organization is well documented on MSDN, and the questions has been raised numerous times. An interesting question is whether a 32-bit application can effectively manage memory amounts exceeding address space limits.

Back in 80386 times, the systems could address megabytes of RAM in 16-bit code through XMS and EMS services. The application could access “high” memory addresses by requesting mapping portions of RAM into lower megabyte address space. In some way similar technique is also here for 32-bit applications in Windows through use of file mappings.

A regular memory backed file mapping requests Windows to reserve a memory block which becomes available for mapping into address space of one or more processes. Creating file mapping itself does not imply mapping and this leaves a great option for the owner to allocate more data than it can actually map into address space: if 32-bit process virtual address space is fundamentally constrained, the file mapping allocation space is more loosely limited by amount of physical memory and paging file. The application can allocate 2, 3, 4 and more gigabytes of memory – it just cannot still map it all together into address space and make it available simultaneously.

The FileMappingVirtualAddress utility does a simple thing:

• on startup it allocates (CreateFileMapping) as many 256 MB file mappings as operating system would allow, and shows it in a list
• each time a user checks a box, the application maps (MapViewOfFile) corresponding file mapping into address space; unchecking a box unmaps the view
• the caption shows currently used and maximal available virtual address space

A plain 32-bit version of the application allocated 51 blocks for me (which totals in 13 GB of memory, with 8 GB physical RAM installed in the system). The allocation takes place immediately because the operating system does not actually make all this memory prepared for use – the actual pages would be allocated and ready to use on demand when the application requires them.

The most important part made so obvious is that the 32-bit application succeeds in allocating well over 4 GB, which is maximal virtual address space it can ever get.

The virtual address space in use is only 1641 MB and another request to map an additional section with MapViewOfFile would fail (the default address space limit is 2 GB) – space fragmentation make mapping unavailable earlier than we actually use the whole space, since the API would need to allocate contiguous range of addresses to satisfy the request.

32-bit application built with /LARGEADDRESSAWARE parameter might manage to do more allocations: 64-bit versions of Windows provide 4 GB of addresses to 32-bit processes. 32-bit operating systems might also be extending the limit in case of 4GB RAM Tuning (which would typically be 3 GB of space for a process).

Finally, 64-bit build of the application is free from virtual address space limit as the limit is 8 terabytes. The mapping is again instantaneous because actual RAM will be supplied on first request to mapped pages only.

A binary [Win32, Win32 with /LARGEADDRESSAWARE, x64] and partial Visual C++ .NET 2010 partial source code are available from SVN.

According to CSI: Crime Scene Investigation, Season 06 Episode 13 (17:04), investigators are using snake scope camera with DirectShow AMCAP tool to present the captured image: