All about Windows Media SDKs

How to control "Listen to this Device" feature of Windows 7 programmatically?

Mahatab Ur Rashid — Sun, 20 May 2012 07:50:22 GMT

This is not possible - there is no public API available to control “Listen to this Device” feature. The feature can only be controlled by the user in the Sound control panel.

Disclaimer

Mahatab Ur Rashid — Sat, 19 May 2012 20:26:00 GMT

This is a personal weblog. The opinions expressed here represent my own and not those of my employer.

All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

Why does the NdrClientCall2() API call takes more then 4-5 milliseconds to complete?

Mahatab Ur Rashid — Sat, 19 May 2012 20:20:00 GMT

Question:

Why does the NdrClientCall2() API call takes more then 4-5 milliseconds to complete in my application? In rare cases I even see hundreds of milliseconds (57 millisecond at one time) just for the NdrClientCall2() API call to complete.

In my application no server side processing is involved. My client and server both are running on the same machine. In either case it is a ncacn_np operation, both sides are already connected, all the calls should complete with the same (or about same) delays.

Is it possible to explain what kinds of things might be involved in this delay?

Answer:

For local RPC calls, it is highly recommend that users to use ncalrpc and not ncacn_np. Ncacn_np is primarily for backwards compatibility and new applications should be using ncacn_ip_tcp for remote traffic. If you are using Vista or later, it is recommended to switch to the lower latency fast binding handle path for LRPC. This removes some significant sources of lock contention in the client path, potentially leading to a reduction in delays.

Please check the links below to know more about the fast RPC binding handle.

RpcBindingCreate
http://msdn.microsoft.com/en-us/library/aa375587(VS.85).aspx

RpcBindingBind
http://msdn.microsoft.com/en-us/library/aa375583(VS.85).aspx

RpcBindingUnbind
http://msdn.microsoft.com/en-us/library/aa375613(VS.85).aspx

RpcBindingFree
http://msdn.microsoft.com/en-us/library/aa375588(VS.85).aspx

On the other hand, the occasional delay is not all that odd. A DPC firing, while the test is executing, can easily cause a 3-4ms delay.

Also please remember, Windows is not a real time operating system and there is no way to give any upper bound guarantee for NdrClientCall2() API call.

Why does the TCP three way handshake never tag with DSCP value on Windows XP and Server 2003?

Mahatab Ur Rashid — Sat, 19 May 2012 20:19:00 GMT

Question:

We are trying to introduce QoS into our VOIP services. While working on this we have observed that TCP three way handshake never tag with DSCP value. We have reproduced the issue both in Windows XP and Windows Server 2003 operating systems. My question is why TCP three way handshake never tag with DSCP value? I don’t think this is an expected behavior, RFC 2474 mentioned nothing about this.

Answer:

On Windows XP and Server 2003, QoS DSCP tagging is applied when a data packet is being sent; depending on the DSCP value supplied by the application or the system-wide setting. During the TCP Handshake, since no data is being sent, DSCP marking is not done. This is an issue in the QoS stack of Windows XP and Server 2003.

Please note: This issue is fixed in Windows Vista and Windows 7.

Why does regedit.exe (or any other Microsoft program) crash when I try to create a remote thread into it using the CreateRemoteThread API?

Mahatab Ur Rashid — Sat, 19 May 2012 20:18:00 GMT

Question:

On Windows XP, I am starting regedit.exe in suspended mode and forcing it to call the LoadLibrary() API to load an external DLL by using the CreateRemoteThread API. After loading the DLL, when I try to resume the suspended thread, the application terminates. Is this a known issue?

Answer:

Creating a remote thread into another process is a poor way to build extensibility into an application. Extendable applications should have some form of an API, a scripting language, plug-in DLL support, etc.

Regedit.exe was not meant to be extended by any means—it has no API and no plug-in interface and therefore does not expect to run any code or threads which are not built into it. Therefore, it also is not designed to run properly when another process calls the CreateRemoteThread to start a new thread within it. It may run or it may not. If it runs without a problem, it is only by coincidence.

In fact, Microsoft strongly discourages using CreateRemoteThread/CreateRemoteThreadEx to start a thread in any process. Its original purpose is to write debuggers and profilers. Even with these tools, creating a thread in another process has a risk that the target process can fail. Although the APIs themselves are documented and they will create a thread in another process (as documented), the effects the new thread has on the target process completely depend on what the target process and the new thread do – how they interact. It’s the latter that causes the all the problems.

When you create a new thread in a process that doesn’t expect it, there are many interactions which can occur. Here are some things that can happen:

a. The new thread requires a stack in the application’s address space. The application may want that memory for something else. Perhaps the application will fail to make an allocation and then crash because it can’t recover from something that should “never” happen.

b. It causes all the DllMain() functions of all the DLLs to get called for DLL_THREAD_ATTACH. One of these could call an API which shouldn’t be called from DllMain(), causing a deadlock.

c. It causes an extra DLL to get loaded somewhere in the process’s address space. It could be that the DLL is loaded into a place where the app wants to allocate memory. The DLL may load at its preferred address space or it may not—it depends on what is already in the process’s memory.

d. The application may use the single-threaded CRT (C runtime library) which now could have multiple threads calling it. Since the single-threaded CRT doesn’t set up the necessary data structures and locks to handle multiple threads, the CRT can crash.

e. The injected code could simply have a bug and cause the application to crash.

f. The thread could cause a deadlock if it uses any synchronization objects that other parts of the application use.

g. Anti-malware and anti-virus programs may get triggered and kill the target process, especially if it is a known administrative tool that should be prevented from being hacked.

Microsoft’s efforts to make the platform more secure means we invest in technologies like DEP (data execution prevention) which happen to do more than simply prevent someone from executing data. DEP also prevent exception handlers from executing in dynamically allocated code (because malware uses this technique), they may mark portions of the address space as no-access so that a DLL can’t be injected, address space layout randomization, required executable signing for kernel-mode modules, etc. Microsoft will continue to improve the security of its products by similar technical means, so there is a greater chance in the future these techniques such as creating remote threads will fail more frequently. (At the same time, a provision is made to allow debuggers to do what they need to do to be useful.)

How to check SLP 1.0 values from the BIOS using Win32 API?

Mahatab Ur Rashid — Sat, 19 May 2012 20:14:00 GMT

Question:

Is there any API available to check SLP 1.0 values from the BIOS?

Answer:

Yes, you can use EnumSystemFirmwareTables API for that.

EnumSystemFirmwareTables API enumerates all system firmware tables of the specified type. It supports 3 types of firmware table provider.

The ACPI firmware table provider
The raw firmware table provider and
The raw SMBIOS firmware table provider

Where, the raw firmware table provider ('FIRM') returns a list of DWORD table identifiers. Each identifier corresponds to the beginning of a physical address range. Currently, this provider returns 'C000' and 'E000'. These values correspond to physical memory from 0xC0000 to 0xDFFFF and 0xE0000 to 0xFFFFF, respectively.

To check values of SLP 1.0 from the BIOS we need to access data from the physical memory location 0xE0000 to 0xFFFFF.

We also have the following alternatives to read data from low physical memory:

Retrieve the SMBIOS properties using WMI. Many individual properties are contained in the Win32 classes. One can also retrieve the raw SMBIOS data in a single buffer using the MSSMBios_RawSMBiosTables class.
Use the GetSystemFirmwareTable function to read the raw SMBIOS firmware table.

Links:

EnumSystemFirmwareTables Function
http://msdn.microsoft.com/en-us/library/ms724259(VS.85).aspx

GetSystemFirmwareTable Function
http://msdn.microsoft.com/en-us/library/ms724379(VS.85).aspx

Does H264 decoder support low latency mode on Windows 7?

Mahatab Ur Rashid — Thu, 17 May 2012 10:47:00 GMT

No, there is no way to put H264 decoder into a low latency mode on Windows 7.

How to programmatically set WMP the default player of Windows Vista and Windows 7?

Mahatab Ur Rashid — Thu, 17 May 2012 10:43:00 GMT

Here is the API that one can use to set the default playback application of Windows Vista and Windows 7:

IApplicationAssociationRegistration::SetAppAsDefaultAll Method
http://msdn.microsoft.com/en-us/library/bb776338(v=VS.85).aspx

This method takes only one parameter - a pointer to a null-terminated Unicode string that specifies the registered name of the application. In this case it will be “Windows Media Player”.

Silverlight 5 MediaElement does not support PlaybackRate for streaming

Mahatab Ur Rashid — Tue, 08 May 2012 09:24:00 GMT

Silverlight 5 MediaElement does not support PlaybackRate for streaming (no MSS or WMS streaming). PlaybackRate is supported only for progressive content.

Does WIA Automation Layer 2.0 support duplex scan?

Mahatab Ur Rashid — Wed, 02 May 2012 04:21:00 GMT

WIA Automation Layer 2.0 doesn’t support duplex scan. This is by design.

WIA Automation Layer 2.0 is based on WIA 1.0. The issue is not related to WIA 1.0, but the way automation layer has been designed to use WIA 1.0 for functionalities.

Use native WIA 2.0 or WIA 1.0 (preferably 2.0, if the target OS is Windows Vista or newer) directly to avoid this problem.