When using System Center Configuration Manger 2007 R2 (SCCM) with Intel vPro/AMT technology, there’s two stages to the provisioning process. In the second stage the SCCM server attempts to connect to the device that’s being provisioned. This can fail if the SCCM server has a proxy configured without the required proxy exceptions resulting in the error below:
Error: Can not finish WSMAN call with target device. 1. Check if there is a winhttp proxy to block connection. 2. Service point is trying to establish connection with wireless IP address of AMT firmware but wireless management has NOT enabled yet. AMT firmware doesn’t support provision through wireless connection. 3. For greater than 3.x AMT, there is a known issue in AMT firmware that WSMAN will fail with FQDN longer than 44 bytes. (MachineId = 11578)
From the command prompt enter “proxycfg -d” to bypass the proxy. Alternatively, open IE, set proxy server, tick “Bypass proxy server for local addresses” and enter *.%YOURDOMAIN%. Next, from the command prompt enter “proxycfg -u”. This import the proxy settings from IE.
When running a WPF click once application from a network drive, I got the error “Value does not fall within the expected range” . The reason for the error was an “&” in the name of the folder that contained the application.
During a period of network issues some of our Windows Server 2008 R2 machines rebooted. Further investigation showed that the servers had experienced a Blue Screen Of Death (BSOD) and rebooted. Most BSOD incidents are caused by faulty drivers. It’s possible to look at the memory dump that’s created when the BSOD occurs and determine which driver caused the crash. This is the method I use.
First download and install the Debugging Tools for Windows from http://www.microsoft.com/whdc/devtools/debugging/default.mspx. Download either the 32bit or 64bit version depending upon the bit type of the operating system that experienced the BSOD. See here for more information: http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx#E1C
Next create two folders in the root of c:\ called Symbols and Dump.
Copy the memory dump from the machine that crashed from c:\Windows to c:\Dump. The dump file will probably be called MEMORY.DMP
Load WinDbg from the Debugging Tools for Windows folder in the Start Menu
Go to File -> Symbol File Path… Paste SRV*C:\symbols*http://msdl.microsoft.com/download/symbols into the Symbol path box and click OK.
Go to File -> Open Crash Dump and select the MEMORY.DMP file in c:\Dump and click OK. In a few seconds text will start to appear in the debug box.
When the text has finished loading click the !analyze -v link below the Bugcheck Analysis box as below
Once the process has finished you’ll see text similar to below. IMAGE_NAME is the driver that caused the BSOD. In my case it’s basp.sys, which is a Broadcom driver. Google the IMAGE_NAME value to find out the driver name, then search for an updated version.
An application that transfers users’ time from our time recording system to our accounts system was failing to run. A support call had been logged with the supplier, but it was taking too long to get a fix. Looking in the error log for the application I could see:
01/11/2010 15:15:00 Connected to: DTE
01/11/2010 15:15:30 Error Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
In the same folder as the failing exe was a config file. Inside the config file were the URLs for two web services as well as some stored procedure names. I checked the webservice URLS and they loaded fine, so the error was probably with one of the stored procedures. I knew the application was written in C#, so I used the Red Gate .NET Reflector http://www.red-gate.com/products/reflector/ to open the exe so I could take a look at the source code. I searched for “Connected to:” and went to the section of code that was causing the problem. I could now see the stored procedure the application was running. I started SQL Server Management Studio and opened the stored procedure to see what it was doing. It took the form:
Running the SELECT statement took 31 seconds, checking this against the error log showed the application was timing out in 30 seconds. A quick check of the source code in .NET Reflector showed the code was using a SqlDataAdapter Select command. The default timeout for the Select command is 30 seconds. I altered the stored procedure to run in batches, which took less that 30 seconds. Running the application showed this had fixed the problem. Next step, get the application developers to introduce a more permanent fix….