Category Archives: MSDN Blog - Page 4

SPDiag Error Creating a Snapshot

SPDiag Error Creating a Snapshot
Many people see error messages when attempting to create an SPDiag snapshot. In my experience the root cause is either the PowerShell remoting configuration or the credential delegating group policy. Sometimes this is not obvious if you only see a vague, generic error.
First, consider what happens during a snapshot. There are several steps, as implied by the TechNet description (h ttp://technet.microsoft.com/en-us/library/hh144782.aspx )
You can take snapshots…(read more)

SPDiag Error Creating a Snapshot

SPDiag Error Creating a Snapshot
Many people see error messages when attempting to create an SPDiag snapshot. In my experience the root cause is either the PowerShell remoting configuration or the credential delegating group policy. Sometimes this is not obvious if you only see a vague, generic error.
First, consider what happens during a snapshot. There are several steps, as implied by the TechNet description (h ttp://technet.microsoft.com/en-us/library/hh144782.aspx )
You can take snapshots…(read more)

Disclaimer

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 TCP three way handshake never tag with DSCP value on Windows XP and Server 2003?

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.

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

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:

  1. 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.
  2. 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

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

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:

  1. 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.
  2. 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

NUI, Kinect: Robotic Triage Nurse

In this video, Craig Mundie shows the prototype of a Robotic Triage Nurse that can be used in developing countries and elsewhere!

 

NUI, Kinect: Robotic Triage Nurse

In this video, Craig Mundie shows the prototype of a Robotic Triage Nurse that can be used in developing countries and elsewhere!

 

NUI, Kinect: Robotic Triage Nurse

In this video, Craig Mundie shows the prototype of a Robotic Triage Nurse that can be used in developing countries and elsewhere!

 

NUI, Kinect: Robotic Triage Nurse

In this video, Craig Mundie shows the prototype of a Robotic Triage Nurse that can be used in developing countries and elsewhere!