Is Windows Kernel safe from corruptions that could happen in User mode

I'm currently performing a kernel debug with liveKD.

In all the cases where my blocking happens ( a ::CloseHandle() function call which never returns ) I happen to have a stacktrace which blocks in the kernel on a synchronisationEvent.

But when I do !object 12345678 if 123456789 is my synchronisationEvent as reported in the thread information of the process, it says Not a valid object (ObjectType invalid).

I'm worrying if corruptions at our application level in user mode could corrupt the kernel ? Does windows guarantee anything like a seperation of the memory spaces that would prevent from something like that ?

The code of the application uses C++, COM/DCOM, and Win32 intensively.

One comment asked for more information about the stacktrace and the handle type. In this case it is related to serial com port. But I think I also have it for file handles (not debugged those cases yet) This is the kind of stacktrace I have:

        THREAD 856a2d48  Cid 0660.0350  Teb: 7ff25000 Win32Thread: ffaaedd8 WAIT: (Executive) KernelMode Non-Alertable
            860c6f9c  SynchronizationEvent
        IRP List:
            babea5d8: (0006,01d8) Flags: 00000404  Mdl: 00000000
        Not impersonating
        DeviceMap                 89809fc8
        Owning Process            86212d40       Image:         DataCaptorIS.exe
        Attached Process          N/A            Image:         N/A
        Wait Start TickCount      27315407       Ticks: 6067021 (1:02:17:26.134)
        Context Switch Count      2259           IdealProcessor: 0
        UserTime                  00:00:04.976
        KernelTime                00:00:02.184
        Win32 Start Address 0x775c03e9
        Stack Init 8aa0dfd0 Current 8aa0da98 Base 8aa0e000 Limit 8aa0b000 Call 0
        Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
        ChildEBP RetAddr  Args to Child
        8aa0dab0 824bfced 856a2d48 00000000 8ab00120 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
        8aa0dae8 824beb4b 856a2e08 856a2d48 860c6f9c nt!KiSwapThread+0x266
        8aa0db10 824b856f 856a2d48 856a2e08 00000000 nt!KiCommitThreadWait+0x1df
        8aa0db88 914539fb 860c6f9c 00000000 00000000 nt!KeWaitForSingleObject+0x393
        8aa0dbcc 82478c1e 860c6f98 babea5d8 babea73c serial!SerialClose+0x332 (FPO: [Non-Fpo])
        8aa0dbe4 886206b9 babea5d8 861986d0 bc859308 nt!IofCallDriver+0x63
        8aa0dc08 82478c1e 861986d0 860c6890 00000800 serenum!Serenum_CreateClose+0x77 (FPO: [Non-Fpo])
        8aa0dc20 82673be6 84aa7a00 bc8592f0 00000000 nt!IofCallDriver+0x63
        8aa0dc64 826647c9 bc859308 bc859308 bc8592f0 nt!IopDeleteFile+0x10c
        8aa0dc7c 824ba1e0 00000000 856a2d48 bc8592f0 nt!ObpRemoveObjectRoutine+0x59
        8aa0dc90 824ba150 bc859308 82687556 960a5578 nt!ObfDereferenceObjectWithTag+0x88 (FPO: [0,0,3])
        8aa0dc98 82687556 960a5578 856a2d48 00000c80 nt!ObfDereferenceObject+0xd (FPO: [0,1,0])
        8aa0dcdc 8268727c 960a5578 a7d21900 86212d40 nt!ObpCloseHandleTableEntry+0x21d
        8aa0dd0c 82687616 86212d40 856a2d01 0763f3b4 nt!ObpCloseHandle+0x7f
        8aa0dd28 8247f8a6 00000c80 0763f3b8 775d7094 nt!NtClose+0x4e
        8aa0dd28 775d7094 00000c80 0763f3b8 775d7094 nt!KiSystemServicePostCall (FPO: [0,3] TrapFrame @ 8aa0dd34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
        0763f3b8 00000000 00000000 00000000 00000000 0x775d7094

This happen happen after that kind of code that should have canceled and purged any IRP:

::CancelIoEx(m_handle_to_serial_port_com);
WaitForRequestToComplete(); // our function calls ::GetOverlappedResult(..., bWait) for any OVERLAPPED that was pending, with bWait == TRUE

::PurgeComm(m_handle_to_serial_port_com);
WaitForRequestToComplete(); // our function calls ::GetOverlappedResult(..., bWait) for any OVERLAPPED that was pending, with bWait == TRUE

::CloseHandle(m_handle_to_serial_port_com)