I’m trying to use Sitecore serialization handlers to serialize some items, and if I serialize my items in the .item format, everything works fine. But, when I update the Sitecore serialization config to use YAML instead of the default, my IIS starts to trigger a w3wp generic error.

I already have checked the logs and there is nothing there, I also checked the windows log events, and the only thing there is that KERNELBASE.dll has failed. So, I have no clue why this is happening when the only change that I did was to change the serialization type from default to YAML.

Technical details:

Sitecore version 10.1.0
OS: Windows 10-64x

handler configuration which is under the following path:


<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/">
        <event name="item:renamed">
            <handler type="Sitecore.Data.Serialization.ItemHandler, Sitecore.Kernel"
        <event name="item:saved">
            <handler type="Sitecore.Data.Serialization.ItemHandler, Sitecore.Kernel"
        <event name="item:deleted">
            <handler type="Sitecore.Data.Serialization.ItemHandler, Sitecore.Kernel"
        <event name="item:versionRemoved">
            <handler type="Sitecore.Data.Serialization.ItemHandler, Sitecore.Kernel"

Serialization configuration:

<setting name="Serialization.SerializationType" value="YAML" /

IIS error on the event log:

Name of the failing application: w3wp.exe, version: 10.0.19041.1, stamp of date/time: 0x58c67bf3
Module failure name: KERNELBASE.dll, version: 10.0.19041.2193, stamp of date/time: 0x7f7062e1
Execption code: 0xe0434352
Deattachment failure: 0x000000000002cd29
ID processing failure: 0x80b4
Beginning time of the failure application falha: 0x01d8f9e5105f7b73
Path of the failure application: c:\windows\system32\inetsrv\w3wp.exe
Path of the failure module: C:\Windows\System32\KERNELBASE.dll
Report ID: 7b7182da-efb1-466b-a734-f656fecd8eb4

Anyone know why I'm having this error ?

  • To resolve this issue we required more details like Stack Trace. Could you please enable the "Exception Settings" in Visual Studio with pressing CTR+ALT+E and select "Common Language Runtime Exceptions". This will throw the exception on exact line from where your application is giving an error including full Stack Trace. Nov 18, 2022 at 8:02
  • Do you have the setting in your config <setting name=”SerializationFolder” value=”$(dataFolder)/serialization” /> set? Nov 18, 2022 at 12:32
  • Yes, and it's working fine. For some reason the only weird behavior is this w3wp error window popping out. Nov 18, 2022 at 13:18
  • Is it doing for all the items or a specific one? Did you check only for the single item? Nov 18, 2022 at 13:59
  • It's happening for all items, even if I do not change anything at the time that I change to yaml it starts to have this issue. Nov 18, 2022 at 14:35

1 Answer 1


In SC9.3, my observation is that when I switch from .item serialization to YAML and serialize a single item, the operation actually appears to perform a full re-serialization of all items, which was unexpected. If you have a lot of items in your tree, there could be performance implications.

It's not clear why you need those event handlers. I can see that you sourced them from serializationevents.config.example. If you remove those custom settings I would expect it to work.

Other Suggestions

  • Clear out the serialization folder and event queue before proceeding.
  • Check if you have custom fields that require a custom serializer.
  • Ensure that you have gone through the recommended environment setup steps, such as ensuring that NETWORK SERVICE has access to your web directory.
  • Verify the following serialization settings:
            When generating file names that correspond to item names, the serialization API encodes the "$" and "%" characters, as well 
            as any characters that are invalid in path names as returned by the System.IO.Path.GetInvalidFileNameChars() method. 
            You use this setting to specify any additional characters that must be encoded, for example, to meet the requirements of a source 
            control system that does not allow specific characters in file names.
            Default value: ""
<setting name="Serialization.InvalidFileNameChars" value="" patch:source="Sitecore.Serialization.config"/>
            In Windows, file system paths may not exceed 248 characters in length. The 
            serialization API therefore shortens long path names. This setting specifies the maximum length of the path to the data/serialization 
            folder, which determines how long item paths can be before they are shortened.
            Important: The value of this setting must be the same on every Sitecore instance that accesses the serialized data. 
            Important: If you change this value, remove the contents of the serialization folder and serialize all the items again. 
            Otherwise duplicates of serialized items may appear in the serialization folder.
            Example: A value of "90"  means that item paths longer than 150 characters are shortened. 
            Sitecore reserves 8 characters and 248 - 8 - 90 = 150. 
            Default value: 90
<setting name="Serialization.SerializationFolderPathMaxLength" value="90" patch:source="Sitecore.Serialization.config"/>
            Defines serialization type. Possible variants: default and YAML
            Default value: default
<setting name="Serialization.SerializationType" value="default" patch:source="Sitecore.Serialization.config"/>
            Points to the root of the serialized databases tree (when using the serialization functionality).
            Default value: $(dataFolder)/serialization
<setting name="SerializationFolder" value="/App_Data/serialization" patch:source="Sitecore.Serialization.config"/>
            NOTE: This setting is only required when the 'Serialization.SerializationType' setting is set to YAML.
            Sitecore item names can become so long that they cannot fit on the filesystem without hitting the max path length.
            This setting controls when to truncate item file names that are extremely long so they fit in the filesystem.
            The value must be less than MAX_PATH - SerializationFolderPathMaxLength - Length of GUID - length of file extension.
            Default value: 30
<setting name="Serialization.MaxItemNameLengthBeforeTruncation" value="30" patch:source="Sitecore.Serialization.config"/>
            NOTE: This setting is only required when the 'Serialization.SerializationType' setting is set to YAML.
            If set to 'true', user syncing deletes matching users that are not serialized, in the same way as item syncing does.
            If set to 'false', users are only added or updated, in the same way as New Items Only item syncing works but updates are also synced.
<setting name="Serialization.Security.RemoveOrphans" value="true" patch:source="Sitecore.Serialization.config"/>


<fieldFormatters patch:source="Sitecore.Serialization.config">
            NOTE: These setting are only required when the 'Serialization.SerializationType' setting is set to YAML.
            These settings define how specific item field types are serialized to the file system.
  <fieldFormatter type="Sitecore.Data.Serialization.Yaml.Formatting.XmlFieldFormatter, Sitecore.Kernel"/>
  <fieldFormatter type="Sitecore.Data.Serialization.Yaml.Formatting.MultilistFormatter, Sitecore.Kernel"/>
  <fieldFormatter type="Sitecore.Data.Serialization.Yaml.Formatting.CheckboxFieldFormatter, Sitecore.Kernel"/>
  • Alright, give me a day to work on this and I will get back with the results. Nov 18, 2022 at 14:36
  • Sorry for the delay. I've tried as you have mentioned above, but still unsuccessful. I'm considering that this is maybe a issue with my SO? I'm using a corporative machine, and there is a lot of rules and authoring stuff been processed. Nov 21, 2022 at 18:35
  • What is "SO"? What if you try on a vanilla install of SC? That should help pinpoint any issues. Nov 21, 2022 at 19:18
  • Oh, sorry I mean my OS. Typing mistake, I'm going to fix it. And, yes! I think that will be my next step. I'm going to reinstall another laptop and check if I still have the same issue. Nov 21, 2022 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.