{"id":163,"date":"2007-07-16T01:38:52","date_gmt":"2007-07-16T01:38:52","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2007\/07\/16\/bug-on-my-boot-driver-now-what\/"},"modified":"2026-07-27T20:44:45","modified_gmt":"2026-07-27T20:44:45","slug":"bug-on-my-boot-driver-now-what","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2007\/07\/16\/bug-on-my-boot-driver-now-what\/","title":{"rendered":"Bug on my Boot driver! Now what?"},"content":{"rendered":"
\"\"<\/a><\/div>\n

Writing drivers is a task that must be done with little care. After all, any unresolved situation between your code and the operating system will result in a beautiful blue screen. But everything in this life has a cure and fortunately God has created the debugger to deal with these situations. After fixing the problem, it is just to change the .sys<\/strong> file and that’s it. Just changing the file means that the machine is expected to be in a stable condition: then, replace the file on the system and reboot the machine. But life is a surprising box and you may not believe, but most drivers are automagically started. Well, in this case, the only think we can do is to pray that the error does not happen until the driver is replaced. Otherwise, we would have to use some resources, such as putting the hard drive of victim’s machine on another computer to replace the sick driver. When there is no one else’s computer, use the Recovery Console<\/em> in XP to avoid the sick driver being loaded. With some luck, this driver is not a filter attached to something important like disk, video or File System<\/em>. You know, if a filter is not able to be loaded, then the main driver, either. In summary, there is a lot of juggling you can invent to replace a buggy driver that is automatically loaded. Is there anything that does not depend much on luck or even on the creativity?<\/strong> Today, I will talk a bit about the replacing driver system with WinDbg.<\/p>\n

Mapping driver files<\/h3>\n

You can map the driver files so the WinDbg can replace it at the time it’d be loaded. Is not that beautiful? For this, you must use the .kdfiles <\/strong>command. With this command, you make a link between the driver that runs on the Target <\/strong>machine and the one that has been fixed on the Host<\/strong> side. One way to do this is to initially create a file that lists these two drivers. This file should be a simple text file where the syntax is shown below. This file can have any name and extension.<\/p>\n

\n
map <\/pre>\n
\\??\\C:\\Windows\\System32\\drivers\\MyDriver.sys <\/pre>\n
C:\\My_Driver_Project_Folder\\MyDriver.sys<\/pre>\n<\/div>\n
The word map<\/strong> marks the beginning of a mapping; this does not change. Next line is the driver file path to be replaced from. This line should have the same format used in the ImagePath<\/em> value under the driver key that is on registry<\/em>. The last line is another driver path. This path could point at a driver in the Host<\/strong> machine itself or on the network.<\/p>\n
This mapping works only in Windows XP or higher, in the Target<\/strong> machine, obviously. If you’re not familiar with terms like Host<\/strong> and Target<\/strong>, check this post<\/a> out.<\/p>\n
Once created the file, you will use WinDbg to launch the following command:<\/p>\n
\n
kd>.kdfiles C:\\Any_Folder\\MyFileMap.txt<\/pre>\n<\/div>\n
Thereafter, whenever the driver is loaded by the system, the kernel checks whether this file is mapped in the debugger, and if so, WinDbg sends the new driver through the debugger connection, such as serial, USB or firewire. For large files, I recommend using firewire. You must understand that the file on Target<\/strong> system’s disk is replaced by the new version. This means that in the forthcoming launches of our driver, the new version will still be loaded, even if the debugger<\/em> is not connected to the system.<\/p>\n
Does this really work?<\/h3>\n
To make things a little clearer, let’s see a practical example. To do this, we need a very simple driver source, or even useless, which can be found here<\/a>. Let’s change its DriverEntry <\/em>function, so that it will be as shown below:<\/p>\n
\n
NTSTATUS DriverEntry(IN PDRIVER_OBJECT  pDriverObject,<\/pre>\n
                     IN PUNICODE_STRING pusRegistryPath)<\/pre>\n
{<\/pre>\n
    \/\/-f--> Let's use __DATE__ and __TIME__ to change this message<\/span><\/pre>\n
    \/\/      each time this driver is built.<\/span><\/pre>\n
    DbgPrint(\"This driver was built on \"<\/span>__DATE__\" \"<\/span>__TIME__\"\\n\"<\/span>);<\/pre>\n
 <\/pre>\n
...<\/pre>\n<\/div>\n
So, we build an initial version of the driver and we install it on the Target<\/strong> machine in the way you best think, but we’ll assume that after the driver has been installed, the registry will be as shown below.<\/p>\n
\"\"<\/div>\n
If we start the driver, we will have something like the following string in the debugger output:<\/p>\n
\n
This driver was built on Jul 16 2007 00:04:03<\/pre>\n<\/div>\n
Now, we’ll create the mapping file. Here I will save it as Z:\\Sources\\DriverEntry\\Useless\\map.txt<\/em>. Following the same format the driver was registered in the registry, our mapping file should have the following content:<\/p>\n
\n
map<\/pre>\n
\\??\\C:\\Windows\\System32\\drivers\\Useless.sys<\/pre>\n
Z:\\Sources\\DriverEntry\\Useless\\objchk_wxp_x86\\i386\\Useless.sys<\/pre>\n<\/div>\n
Notice that the folder where I saved my file map.txt<\/strong> is the same where the driver sources are. This is just a matter of organization. The mapping file could be in any folder. Then, use the command .kdfiles<\/strong> as shown below. Notice that we list the existing maps simply using the same command without any parameters.<\/p>\n
\n
kd> .kdfiles Z:\\Sources\\DriverEntry\\Useless\\map.txt<\/pre>\n
KD file assocations loaded from 'Z:\\Sources\\DriverEntry\\Useless\\map.txt'<\/pre>\n
 <\/pre>\n
kd> .kdfiles<\/pre>\n
KD file assocations loaded from 'Z:\\Sources\\DriverEntry\\Useless\\map.txt'<\/pre>\n
\\??\\C:\\Windows\\System32\\drivers\\Useless.sys -><\/pre>\n
Z:\\Sources\\DriverEntry\\Useless\\objchk_wxp_x86\\i386\\Useless.sys<\/pre>\n<\/div>\n
Afterwards, we’ll Rebuild<\/strong> the driver (that should change that time stamp) and we will restart it. If everything is right there by your side, you should have an output with a time stamp different from what we had before.<\/p>\n
\n
kd> g<\/pre>\n
But now? I did nothing so far...<\/pre>\n
KD: Accessing 'Z:\\Sources\\DriverEntry\\Useless\\objchk_wxp_x86\\i386\\Useless.sys'<\/pre>\n
 (\\??\\C:\\Windows\\system32\\drivers\\Useless.sys)<\/pre>\n
  File size 2K.<\/pre>\n
MmLoadSystemImage: Pulled \\??\\C:\\Windows\\system32\\drivers\\Useless.sys from kd<\/pre>\n
This driver was built on Jul 16 2007 00:17:04<\/pre>\n<\/div>\n
Well, if this works for a driver with manual start<\/strong> value, then the automatic one also should work. To see this, change your driver start<\/strong> value to System<\/em> or Automatic<\/em>, do a Rebuild again in the driver, and finally, we will restart the Target <\/strong>machine. When the driver is loaded, we have the automatic replacement of its image. In WinDbg, we will have the following:<\/p>\n
\n
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE<\/pre>\n
Kernel Debugger connection established.<\/pre>\n
Symbol search path is: SRV*c:\\websymbols*http:\/\/msdl.microsoft.com\/download\/symbols<\/pre>\n
Executable search path is: <\/pre>\n
Windows XP Kernel Version 2600 UP Free x86 compatible<\/pre>\n
Built by: 2600.xpsp_sp2_gdr.070227-2254<\/pre>\n
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805533a0<\/pre>\n
System Uptime: not available<\/pre>\n
KD: Accessing 'Z:\\Sources\\DriverEntry\\Useless\\objchk_wxp_x86\\i386\\Useless.sys'<\/pre>\n
 (\\??\\C:\\Windows\\system32\\drivers\\Useless.sys)<\/pre>\n
  File size 2K.<\/pre>\n
MmLoadSystemImage: Pulled \\??\\C:\\Windows\\system32\\drivers\\Useless.sys from kd<\/pre>\n
This driver was built on Jul 16 2007 00:25:38<\/pre>\n<\/div>\n
Yeah, it really works! But what if was my driver a Boot driver?<\/strong> This means that the driver image will be loaded even before the connection is established with WinDbg. Have you heard that what has no remedy, it is remedied? Fortunately, this is not applied here yet. There is a way to make this work, even with Boot drivers.<\/p>\n
Mapping Boot drivers<\/h3>\n
To establish a connection with WinDbg, we need to replace the system loader<\/em> by a special version. This version makes this connection with the Kernel Debugger,<\/em> even before the Boot.ini<\/strong> file is read. For this reason, the connection parameters are fixed with COM1 and baud rate of 115200. This loader version is located in the directory C:\\winddk\\3790\\debug<\/em> of the DDK<\/strong> with its ntldr_dbg<\/strong> name. This file should replace the original loader system version that is at the boot drive root with the ntldr<\/strong> name. The debug version must stay with the same name as the original loader.<\/p>\n
Before rebooting, we need to change the driver’s start<\/strong> value to Boot<\/strong> and remove the ImagePath<\/em> value from the registry. As you may know, boot drivers do not have that luxury of using file paths that have drive letters. At the end of the changes, we should have the registry as shown below.<\/p>\n
\"\"<\/div>\n
As I said earlier, the driver file path format should be the same as it is on registry, but knowing that now there’s no file path in the registry, so we adopt the same forms adopted by the system. Oh! okay! The same format. And what would it be?<\/strong> To see this format, simply restart the system with the debug loader, which should give us the following screen at boot-up.<\/p>\n
\"\"<\/div>\n
This is the time to connect to Windbg using pre-determined parameters connection. This should result in the following output in the debugger.<\/p>\n
\n
Microsoft (R) Windows Debugger  Version 6.7.0005.1<\/pre>\n
Copyright (c) Microsoft Corporation. All rights reserved.<\/pre>\n
 <\/pre>\n
Opened \\\\.\\pipe\\com_1<\/pre>\n
Waiting to reconnect...<\/pre>\n
BD: Boot Debugger Initialized<\/pre>\n
BD: osloader.exe base address 00400000<\/pre>\n
Connected to Windows Boot Debugger 3790 x86 compatible target, ptr64 FALSE<\/pre>\n
Kernel Debugger connection established.<\/pre>\n
Symbol search path is: SRV*c:\\websymbols*http:\/\/msdl.microsoft.com\/download\/symbols<\/pre>\n
Executable search path is: <\/pre>\n
Windows Boot Debugger Kernel Version 3790 UP Checked x86 compatible<\/pre>\n
Primary image base = 0x00000000 Loaded module list = 0x00000000<\/pre>\n
System Uptime: not available<\/pre>\n
The call to LoadLibrary(bootext) failed, Win32 error 0n2<\/pre>\n
    \"The system cannot find the file specified.\"<\/pre>\n
Please check your debugger configuration and\/or network access.<\/pre>\n<\/div>\n
Now you see the Boot.ini<\/strong> selection menu. Select your option and continue loading the system. A list of boot drivers should be presented, which are the ones loaded before the first breakpoint that the debugger<\/em> can stop.<\/p>\n
\n
BD: \\WINDOWS\\system32\\ntoskrnl.exe base address 804EA000<\/pre>\n
BD: \\WINDOWS\\system32\\hal.dll base address 806FF000<\/pre>\n
BD: \\WINDOWS\\system32\\KDCOM.DLL base address 80720000<\/pre>\n
BD: \\WINDOWS\\system32\\BOOTVID.dll base address 80010000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\ACPI.sys base address 80124000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\WMILIB.SYS base address 80001000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\pci.sys base address 80062000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\isapnp.sys base address 80003000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\compbatt.sys base address 8000C000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\BATTC.SYS base address 80013000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\intelide.sys base address 80017000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\PCIIDEX.SYS base address 80019000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\MountMgr.sys base address 80152000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\ftdisk.sys base address 8015D000<\/pre>\n
BD: \\WINDOWS\\System32\\drivers\\dmload.sys base address 80073000<\/pre>\n
BD: \\WINDOWS\\System32\\drivers\\dmio.sys base address 8017C000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\PartMgr.sys base address 801A2000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\VolSnap.sys base address 801A7000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\atapi.sys base address 801B4000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\vmscsi.sys base address 801CC000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\SCSIPORT.SYS base address 801CF000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\disk.sys base address 801E7000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\CLASSPNP.SYS base address 801F0000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\fltMgr.sys base address 801FD000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\sr.sys base address 8021D000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\KSecDD.sys base address 8022F000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\Ntfs.sys base address 80246000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\NDIS.sys base address 802D3000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\Useless.sys base address 8000F000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\Mup.sys base address 80300000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\agp440.sys base address 8031B000<\/pre>\n
Shutdown occurred...unloading all symbol tables.<\/pre>\n
Waiting to reconnect...<\/pre>\n<\/div>\n
Here the connection to the loader<\/em> is closed. A new connection would be established if you had selected the Debug<\/em> entry from Boot.ini<\/strong>, but what we have to note here, is the file path format used to load drivers during system boot. Notice that our test driver is among the drivers from the above list. Let us adopt this same file path format on our mapping file.<\/p>\n
\n
map<\/pre>\n
\\WINDOWS\\System32\\Drivers\\Useless.sys<\/pre>\n
Z:\\Sources\\DriverEntry\\Useless\\objchk_wxp_x86\\i386\\Useless.sys<\/pre>\n<\/div>\n
After modifying the mapping file and save its contents to disk, we update the WinDbg, so it takes this change. Then, we will restart the system.<\/p>\n
\n
kd> .kdfiles Z:\\Sources\\DriverEntry\\Useless\\map.txt<\/pre>\n
KD file assocations loaded from 'Z:\\Sources\\DriverEntry\\Useless\\map.txt'<\/pre>\n
 <\/pre>\n
kd> .reboot<\/pre>\n
Shutdown occurred...unloading all symbol tables.<\/pre>\n
Waiting to reconnect...<\/pre>\n
BD: Boot Debugger Initialized<\/pre>\n
Connected to Windows Boot Debugger 3790 x86 compatible target, ptr64 FALSE<\/pre>\n
Kernel Debugger connection established.  (Initial Breakpoint requested)<\/pre>\n
Symbol search path is: SRV*c:\\websymbols*http:\/\/msdl.microsoft.com\/download\/symbols<\/pre>\n
Executable search path is: <\/pre>\n
Module List address is NULL - debugger not initialized properly.<\/pre>\n
WARNING: .reload failed, module list may be incomplete<\/pre>\n
KdDebuggerData.KernBase < SystemRangeStart<\/pre>\n
Windows Boot Debugger Kernel Version 3790 UP Checked x86 compatible<\/pre>\n
Primary image base = 0x00000000 Loaded module list = 0x00000000<\/pre>\n
System Uptime: not available<\/pre>\n
The call to LoadLibrary(bootext) failed, Win32 error 0n2<\/pre>\n
    \"The system cannot find the file specified.\"<\/pre>\n
Please check your debugger configuration and\/or network access.<\/pre>\n<\/div>\n
The same message sequence happens, but this time, the mapping is done as it should and we have the following output when the boot drivers are loaded.<\/p>\n
\n
BD: osloader.exe base address 00400000<\/pre>\n
BD: \\WINDOWS\\system32\\ntoskrnl.exe base address 804EA000<\/pre>\n
BD: \\WINDOWS\\system32\\hal.dll base address 806FF000<\/pre>\n
BD: \\WINDOWS\\system32\\KDCOM.DLL base address 80720000<\/pre>\n
BD: \\WINDOWS\\system32\\BOOTVID.dll base address 80010000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\ACPI.sys base address 80124000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\WMILIB.SYS base address 80001000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\pci.sys base address 80062000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\isapnp.sys base address 80003000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\compbatt.sys base address 8000C000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\BATTC.SYS base address 80013000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\intelide.sys base address 80017000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\PCIIDEX.SYS base address 80019000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\MountMgr.sys base address 80152000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\ftdisk.sys base address 8015D000<\/pre>\n
BD: \\WINDOWS\\System32\\drivers\\dmload.sys base address 80073000<\/pre>\n
BD: \\WINDOWS\\System32\\drivers\\dmio.sys base address 8017C000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\PartMgr.sys base address 801A2000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\VolSnap.sys base address 801A7000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\atapi.sys base address 801B4000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\vmscsi.sys base address 801CC000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\SCSIPORT.SYS base address 801CF000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\disk.sys base address 801E7000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\CLASSPNP.SYS base address 801F0000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\fltMgr.sys base address 801FD000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\sr.sys base address 8021D000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\KSecDD.sys base address 8022F000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\Ntfs.sys base address 80246000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\NDIS.sys base address 802D3000<\/pre>\n
KD: Accessing 'Z:\\Sources\\DriverEntry\\Useless\\objchk_wxp_x86\\i386\\Useless.sys'<\/pre>\n
 (\\WINDOWS\\System32\\Drivers\\Useless.sys)<\/pre>\n
  File size 2K.BD: Loaded remote file \\WINDOWS\\System32\\Drivers\\Useless.sys<\/pre>\n
 <\/pre>\n
BlLoadImageEx: Pulled \\WINDOWS\\System32\\Drivers\\Useless.sys from Kernel Debugger<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\Useless.sys base address 8000F000<\/pre>\n
BD: \\WINDOWS\\System32\\Drivers\\Mup.sys base address 80300000<\/pre>\n
BD: \\WINDOWS\\system32\\DRIVERS\\agp440.sys base address 8031B000<\/pre>\n
Shutdown occurred...unloading all symbol tables.<\/pre>\n
Waiting to reconnect...<\/pre>\n<\/div>\n
And later, our proof that the driver file has been successfully replaced.<\/p>\n
\n
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE<\/pre>\n
Kernel Debugger connection established.  (Initial Breakpoint requested)<\/pre>\n
Symbol search path is: SRV*c:\\websymbols*http:\/\/msdl.microsoft.com\/download\/symbols<\/pre>\n
Executable search path is: <\/pre>\n
Windows XP Kernel Version 2600 UP Free x86 compatible<\/pre>\n
Built by: 2600.xpsp_sp2_gdr.070227-2254<\/pre>\n
Kernel base = 0x804ea000 PsLoadedModuleList = 0x8056d620<\/pre>\n
System Uptime: not available<\/pre>\n
This driver was built on Jul 16 2007 01:18:53<\/pre>\n<\/div>\n
I assure you that this could still save your life if you had a File System<\/em> filter with a bug in its DriverEntry<\/em> on a customer's machine. The expression of panic when the customer sees his machine restarting in an endless loop is interesting, but keeping your job is a little more interesting.<\/p>\n
See you!<\/p>\n","protected":false},"excerpt":{"rendered":"
Writing drivers is a task that must be done with little care. After all, any unresolved situation between your code and the operating system will result in a beautiful blue screen. But everything in this life has a cure and fortunately God has created the debugger to deal with these situations. After fixing the problem, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-163","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/163","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=163"}],"version-history":[{"count":3,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/163\/revisions"}],"predecessor-version":[{"id":304,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/163\/revisions\/304"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=163"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=163"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=163"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}