FAQ: Microsoft Dynamics AX Kernel Hotfixes



非常有用的文章。

This blog article attempts to address some of the questions we are commonly asked relating to kernel hotfixes. It is primarily written for AX 2012, R2 and R3 but many of the concepts are relevant to previous versions. It briefly covers the other types of AX hotfix but this is primarily to illustrate what a kernel hotfix is and how it differs from the other types. This article also does not go into great detail about the hotfix installation process.

Please refer to the following links for more detailed information on installing all the different variations of hotfix package for Dynamics AX:

http://technet.microsoft.com/en-us/library/hh335183.aspx

http://support.microsoft.com/kb/893082

If any of your questions on this topic still remain unanswered, please leave a comment below and we will try to answer them for you!

Q1: What is a kernel hotfix?

A kernel hotfix updates the binary source files and other supporting files for all the AX components.

Kernel hotfixes are therefore also commonly referred to as binary hotfixes. Some examples of the files a kernel fix may update are the executable files (ax32.exe, ax32serv.exe) and assemblies (Microsoft.Dynamics.AX.*.dll). The installer will replace each file that needs patching with a newer version.

Q2: What is an application hotfix?

An application (X++) fix updates objects in the AOT.

It can make updates in the SYP, GLP, FPP & SLP layers (the layers reserved for Microsoft code). These changes are made in the AX model store in AX 2012 and later versions.

Q3: What are the major differences between these two types of fix?

A kernel fix is always cumulative.

Each, new kernel build contains every kernel fix previously published.

An application fix is NOT cumulative.

Application fixes will normally update just the objects that need fixing in order to resolve a specific issue. However, it may also need to update any dependencies (i.e. additional objects in the AOT that the “fixed”objects reference and that have also been fixed themselves).

The exception is a cumulative update or service pack, where both the kernel and application patches are cumulative.

Q4: What is the relationship between the application code and the kernel?

The AX kernel provides the underlying functionality that supports the execution of the application (X++) code.

The X++ application code is an interpreted language and the X++ interpreter is a part of the AX kernel. The kernel manages the resources used during the execution of X++ and performs garbage collection to clean up X++ objects and other resources that go out of scope.

The AX kernel is primarily programmed in C++ but also includes .NET assemblies. It is Microsoft-proprietary code and is not published externally, whereas the X++ source code is visible in the AOT.

The X++ programming language includes system classes, which are actually kernel classes (i.e. they are implemented in C++). For more information, refer to http://msdn.microsoft.com/en-us/library/aa853470.aspx

Q5: What is a hybrid fix?

A hybrid fix includes patches for both the kernel and application code.

It’s similar to a cumulative update/rollup except that the application part of a hybrid fix will target a specific issue and is therefore not cumulative. Another similarity with a cumulative update is that you can apply just the kernel or just the application update.

Hybrid fixes are released when changes in the application code reference new functionality in the kernel (or vice-versa). However, these references are implemented in such a way as to ensure that the application will still run normally when only the application or kernel portion of the fix is installed (see Q8 for more on this).

Q6: Do I need to update my customizations after applying a kernel hotfix?

No, you do not need to resolve code conflicts between the patched Microsoft code and custom application code.

It’s a common misconception that applying the kernel hotfix will cause conflicts with custom X++ code. This only applies to application fixes, which as mentioned above will update the X++ source code in the lower, Microsoft-owned layers and can therefore affect customizations in higher layers.

Q7: Do I need to test a kernel hotfix before I implement it in Production?

You should always follow your normal processes for testing changes to your Dynamics AX environment before introducing the kernel hotfix into Production.

Each fix is tested before release, but it doesn’t completely guarantee against the introduction of undesired behaviour in a customer’s environment; every environment is different with a unique combination of hardware, configuration settings, integrations and custom application code and it’s simply not possible to test every combination before the hotfix is published.

You should always take appropriate measures that minimize the risk of downtime and ensure your business critical functionality works as expected after the fix is applied.

For more information on how to implement a Dynamics AX hotfix, please refer to the following TechNet article:

http://technet.microsoft.com/en-us/library/hh335183.aspx

Q8: Is it supported to have a different kernel and application build?

YES, it is supported to have different builds for the application and the kernel BUT… they must be for the same version and service pack level.

Our Product Group ensure that dependencies between the application and kernel are not introduced when creating AX hotfixes. Dependencies between the application and kernel builds can only be introduced in a new product version and a new service pack (NOT in a rollup/cumulative update).

We also recommend having a kernel build that is the same or higher build than the application build. Applying a kernel update is normally a simpler process than updating the application code, so in the case of applying a cumulative update it makes sense to apply the kernel part of the update as well as the application part. This also ensures that you get the full benefit from any hybrid fixes, which as mentioned above require updates in both the kernel and application to function fully.

Examples:

Application build	Kernel build	Supported?
5.0.593.0 (AX2009 RTM)	5.0.1500.6491 (AX 2009 SP1 RU8)	NO (the application build is for RTM, whereas the kernel is for SP1)
6.2.1000.4051 (AX2012 R2 CU7)	6.2.1000.1437 (AX2012 R2 CU6)	YES…but not recommended! (The kernel build is lower than the application build)
6.3.164.0 (AX2012 R3 base)	6.3.1000.930 (AX2012 R3 latest kernel*)	YES (the kernel build is higher than the application build but both are for AX 2012 R3 with no service pack)

* True at the time of writing. See Q10 below for ways to find the latest kernel.

Q9: Is it supported to have different kernel builds for different AX components in the same environment?

NO it is NOT supported. Customers should always apply the kernel fix to every AX component in the same environment.

It’s possible that unexpected behaviour could result from a kernel mismatch. In the latest versions of AX, the AOS throws a warning message to the event logs (event 151) if a client tries to connect to it and has a different kernel version.

The screenshot below is taken from the AX hotfix installer when applying a kernel fix for AX 2012 R2. It shows a list of all AX components that require updating (NOTE: ignore the checkboxes – only a few AX components were installed on my system, so some of the checkboxes were automatically disabled):

 

  
Q10: I have found a hotfix for my issue, should I install the specific hotfix referenced by the KB article?

Not always – if you are experiencing an issue that has been fixed in the AX kernel then download and install the very latest, kernel hotfix available for your product version and service pack.

As mentioned above, kernel hotfixes are cumulative so it normally makes sense to install the very latest kernel build. To recognise whether a fix is for the kernel or the application code, refer to http://technet.microsoft.com/en-us/library/hh335183.aspx. 

To find the most recent releases, you can refer to the following post on our blog, which we update on a regular basis:

http://blogs.msdn.com/b/axsupport/archive/2012/03/29/overview-of-ax-build-numbers.aspx

You can also log a support case to request the latest kernel hotfix package. Support cases that are logged to request hotfixes will normally be closed free-of-charge.

Q11: Can I uninstall a kernel hotfix?

Yes, a kernel hotfix can be uninstalled using the standard Windows functionality for uninstalling program updates

(i.e. by going to Control Panel, Programs, Programs and Features,Installed Updates).

The same is not true for application hotfixes, as these will add or replace models in your AX model-store and therefore cannot be removed in the same way.

As mentioned above, you must always ensure that all AX components have matching kernel versions when applying or removing a kernel hotfix.

Q12: I am experiencing crashes in my AX environment, should I install the latest kernel?

In most cases, YES! Almost all, known crash-causing bugs are resolved in the latest kernel build.

This is because problems in X++ code are normally detected and handled by the kernel’s exception handling framework or by the X++/IL compiler, whereas unexpected exceptions in the kernel force the operating system to terminate the program.

Troubleshooting crashes often requires a lot of time-consuming investigation work. Applying the latest, cumulative kernel update is the most efficient way to troubleshoot and ensures that we do not investigate issues that have already been resolved.

Unless you have already captured enough information to help diagnose the issue then it is normally recommended to apply a kernel update.

For example, we will almost always require a full, user-mode crash dump file. This type of file will only be captured if you have set up Windows Error Reporting or enabled a crash rule in a debugging tool (e.g. Debug Diagnostic). In certain cases, we may need to analyse more than one dump file. Rather than wait for further crashes to occur and risk more downtime in your environment, a better alternative could be to proactively update the kernel.