Whereas most Verifier error messages are rather descriptive, this one is not really:
VERIFIER STOP 00000200 : pid 0x2B4: Thread cannot own a critical section. 0000104C : Thread ID. 05274FDC : Critical section address. 09D88FE0 : Critical section debug information address. 010135D4 : Critical section initialization stack trace. Why should not this thread be allowed to own a critical section? What is Application Verifier trying to tell us? Luckily, the stack trace gives a hint:
Continue »
As of Windows Vista, basically all applications require a manifest in order to at least declare UAC compliance. Visual Studio has builtin support for creating and embedding manifests, so when using VS to build applications, using manifests is straightforward. However, when building a user mode application with the WDK and build.exe, things are a little different. Looking at the WDK documentation, manifests remain unmentioned – both in the context of UAC and SXS.
Continue »
Functions that take a buffer and a corresponding buffer size as a parameter are ubiquitous. As an example, consider this function declaration:
/** Routine Description: …queries some value… Parameters: BufferSize - size of buffer in WCHARs. Buffer - buffer to store information in. Return Value: ERROR_SUCCESS on success. ERROR_INSUFFICIENT_BUFFER if the buffer is to small. –*/ DWORD QueryInformation( __in UINT BufferSize, __out_ecount(BufferSize) PWSTR Buffer ); ``` If we are to write a testcase for this function, it is important to check that the function properly handles buffers of insufficient size.
Continue »
There are three common error code formats used throughout Windows. In the kernel and native part, NTSTATUS is used exclusively. The Win32 API uses its own error codes (they do not really have a name, so I will refer to them as Win32 error codes) and COM uses HRESULTs – though the separation is not always so sharp, e.g. the safe string functions (StringCch* and friends) also return HRESULTs although they do not belong to COM.
Continue »
When authoring MSI packages, you frequently need the installation to be logged. Instead of repeatedly opening a console to type in msiexec /l* install.log /i foobar.msi, these shell context menu items may speed this process up a little. They do the same as ‘Install’ and ‘Uninstall’ but log everything (/l) to PackageName.msi-install.log or PackageName.msi-uninstall.log, respectively. Here are the registry entries:
Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Msi.Package\shell\LoggedInstall] @="&Logged Install" [HKEY_CLASSES_ROOT\Msi.Packageshell\LoggedInstall\command] @="msiexec.exe /l "%1-install.
Continue »
When testing a custom action, it is usally practical to have the CA write some information to the installer log, so that you can verify that the CA has been called properly. But what if the installer log does not show up your information but instead the installation aborts and the log only states that the custom action returned 3 (ERROR_INSTALL_FAILURE)?
There may be various reasons for this to happen, but the most common reason is probably that your DLL was unable to load because of unsatisfied dependencies.
Continue »
When Windows Installer performs a major upgrade, the position of the RemoveExistingProducts action determines when the uninstall of the old product is performed. Despite efficiency, two factors dominate the decision
What should happen if either the install or the uninstall fails? Should the new product ‘see’ registry entries/files/etc from the existing product or should the new product install ‘start from scratch’? The following table summarizes the four possible approaches.
Continue »
By default, Windows Installer packages are single-language only – no direct support for multi-language packages is currently provided. Creating a multi-lanuage installation package is thus a little more compex – the following provides a summary of the steps required:
Create an english package Compile: candle -dLANG=1033 foo.wxs Link: light -out foo.msi -loc strings-en.wxl foo.wixobj Create the german (or whatever language) package Compile: candle -dLANG=1031 foo.wxs Link: light -out foo-de.msi -loc strings-de.
Continue »
There are situations in which it would be convenient to list which apartment the threads of a process belong to. In case of managed debugging, the !threads command provided by SOS gives this info:
PreEmptive GC Alloc Lock ID ThreadOBJ State GC Context Domain Count APT Exception 0 688 00149528 6020 Enabled 00000000:00000000 00159e68 0 STA 1 f70 00165548 b220 Enabled 00000000:00000000 00159e68 0 MTA (Finalizer) In case of unmanaged debugging, however, no such command exists (at least to my knowledge).
Continue »
Application Verifier: Thread cannot own a critical section
