.NET Questions and Solutions

Symptoms
When you try to activate Windows Vista or Windows Server 2008 over the Internet, the activation may be unsuccessful. Additionally, you may experience one or more of the following symptoms: Activation fails with error code 0×8004FE33. The following Error events may be recorded in the Application log:

Log Name: Application
Source: Software Licensing Service
Event ID: 8198
Level: Error Description: License Activation (SLUI.exe) failed with the following error code: 0×80004005

Log Name: Application
Source: Software Licensing Service
Event ID: 1008
Level: Error Description: Acquisition of Secure Processor Certificate failed. Status Code=hr=0×8004FE33Activation is not successful, and you are not prompted for credentials.
Resolution
This issue may occur when you connect to the Internet through a proxy server where Basic authentication is enabled.
When the proxy server is configured for Basic authentication, the server requires that you type a username and a password. However, the activation user interface does not let you enter these credentials. Therefore, the Basic authentication fails, and activation is not successful.

Symptoms
When you call Win32 Structured Exception Handling (SEH) APIs, such asGetExceptionCode() and GetExceptionInformation(), sometimes the systemreports the following exception code:

0xE06D7363 Sometimes GetLastError() also returnsthis value. This exception code will be used for any error that is raised by the Microsoft Visual C++ compiler through a call to “throw”.
Resolution
All Visual C++ exceptions thrown from code generated by the MicrosoftVisual C++ compiler contain this error code. Because this is a compiler-generated error, the code is not listed in the Win32 API header files. The code is actually a cryptic mnemonic device, with the initial “E” standing for “exception” and the final 3 bytes (0×6D7363) representing the ASCII values of “msc”.

Symptoms
If you use the CommandBuilder object to explicitly get commands for the DataAdapter object as follows:

da.InsertCommand = cb.GetInsertCommand and then run the following Visual Basic .NET code

cb.DataAdapter = Nothing or the following Visual C# .NET code

cb.DataAdapter = null; the commands that you add to the DataAdapter are deleted, and you receive the following error message:

An unhandled exception of type ‘System.NullReferenceException’ occurred in app_name.exe
Additional information: Object reference not set to an instance of an object.
Resolution
CommandBuilder deletes the commands that it generates when it is disassociated from a DataAdapter. CommandBuilder and DataAdapter are linked; when they are unlinked or disassociated, the commands are nulled. This problem does not affect commands that you build from the beginning (from scratch).

Symptoms
You have a Microsoft Visual C++ .NET 2003 application that uses multiple application domains. When you try to call managed code from unmanaged code in a DLL that has already been loaded in another application domain, you may receive the following error message:

An unhandled exception of type ‘System.NullReferenceException’ occurred in mscorlib.dll
Additional information: Object reference not set to an instance of an object.Note In some scenarios, you may receive one of the following error messages:

DllNotFoundException

Illegal Instruction
Resolution
You may notice this problem if your application contains unmanaged code and uses multiple application domains.
For example, if you have an application that uses multiple application domains that use a set of DLLs, you can successfully load and use these DLLs in the first application domain. However, when you try to call the managed code in one of these DLLs from unmanaged code in a different (second) application domain, the behavior that is mentioned in the “Symptoms” section of this article occurs. The application does not load the managed code in the second application domain because the code has already been loaded in another application domain that is in the same process.

Symptoms
This problem occurs when a call is made from unmanaged code to managed code, including direct unmanaged-to-managed calls within a single DLL. For example, the problem may occur when MEC++/IJW is used in ASP.NET applications. In ASP.NET, various events can cause applications to be reloaded into a new AppDomain. If you are using MEC++ components and IJW in this application, you may receive an AppDomainUnloadException error message.
Resolution
As part of the implementation of IJW, when a managed DLL that you created by using the C++ compiler loads, the runtime creates thunks for transitions from unmanaged code to managed code. These thunks contain a reference to the AppDomain in which the DLL loads. The runtime does not re-create these thunks if the DLL loads again; also, the runtime does not update the reference when the original AppDomain unloads and the DLL loads in another AppDomain.
When the program performs a transition from unmanaged code to managed code, the program uses the outdated AppDomain reference to run the managed code. Even if the original AppDomain is still loaded, the code cannot access static fields because the fields are specific to the AppDomain.

Symptoms
Windows reports a random “Fatal Exception 0x has occurred at xxxx:xxxxxxx” error message even though your previous version of Windows or Windows for Workgroups did not.
Resolution
A common cause for this error messages is faulty physical memory (RAM) onthe computer. The following are reasons why your previous version ofWindows may appear to run smoothly while Windows may report a random”Fatal Exception 0x has occurred at xxxx:xxxxxxx” error message:
All operating systems use memory differently. In Windows 3.1, the “bad”memory may be used for holding rarely used data. In Windows, the”bad” memory is used for holding frequently run program information.Windows 3.1 contains comparatively little 32-bit code. Windows usesmuch more 32-bit code. Furthermore, there are subtle differencesbetween the way memory is accessed if it is being accessed for code orif it being accessed for data. Because Windows runs much more32-bit code, these subtle errors show up more often.
In particular, all the 32-bit code in Windows 3.1 resides in one place:at the low-end of physical memory. If the first 4 megabytes (MB) ofmemory can handle 32-bit code, Windows 3.1 works without errors. This istrue even if the topmost physical memory cannot run 32-bit code becauseWindows 3.1 does not run 32-bit code outside the first 4 MB of RAM.
Windows runs 32-bit code in all portions of memory. Therefore,when Windows runs 32-bit code in a section of RAM that cannotrun 32-bit code well, you may receive “Fatal Exception Error0x:xxxxxxxx” error messages.Windows interacts with hardware differently than previous versionsof Windows. This is due partly to Plug and Play and partly to newdrivers that take advantage of the additional capabilities of interfaceadapters. These features may uncover anomalies in the hardware thatnever appeared in previous versions of Windows because earlier versionsdid not attempt to exploit these features.Many new computers do not have memory chips that perform paritychecking; therefore, you may have been encountering parity errors inWindows 3.1 without realizing it because the errors were inrelatively harmless sections of memory. For example, in a MicrosoftWord for Windows document, the word “the” is changed to “tie.”