The Windows kernel is a popular research topic. However, in its details, not all components receive the same amount of attention even though some occupy an interesting situation from a vulnerability research point of view. Among these less studied mechanisms hides the Kernel Shim Engine (KSE). The KSE is a feature ensuring the compatibility of a kernel module with the system. Actually, it orchestrates execution flow redirections whenever an updated API might cause an issue with the module. Even though Microsoft tends to harden the access to privileged space like the kernel, the KSE still enables legitimate hooking and modifications of a driver's behavior without invalidating its signature or triggering protection mechanisms. From an offensive point of view, it is all the more seducing that it is loaded early at boot time, therefore may leverage new vectors of persistence. Unfortunately, fuzzing this kind of components is rather inconvenient as the whole environment is not tailored to quickly run test cases and tends to become unstable pretty badly. The approach we implemented overcome this drawback at the price of lots of headaches and funny anecdotes. The uncommon path we took is moving a Windows kernel component to the Linux userland in order to fuzz it with AFL and a DBI. Our talk will provide feedbacks and highlight issues one could encounter as a newcomer playing with fuzzers, DBIs and kernels.