Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      VirtualBox 4

      Description

      Recently we added the UDF driver by Alter into ReactOS trunk. It builds nicely now due to the efforts of Amine Khaldi and now even for AMD64 and ARM, but booting with it is impossible. Attached a log file made with r68146 on a MSVC2013 build. For a easy way to reproduce, install http://dwn.alter.org.ua/downloads/dwn_1_5_12_sp2.zip on ROS, shutdown, replace dwudf.sys with our built udfs.sys and bootup again. It's not added to the ISOs as long as it does nothing useful.

      UPDATE: sys file already is there. You just need the reg files added here, but beware! These are for dwudf.sys, so you have to fix the name to our udfs.sys

      1. CDRW.reg
        17 kB
        Daniel Reimer
      2. CORE-9816_install_udfs.patch
        0.4 kB
        hater
      3. CORE-9816_lower_debug_output.patch
        6 kB
        hater
      4. CORE-9816_test_udf.iso
        1.19 MB
        hater
      5. CORE-9816_udfs_recognize.patch
        4 kB
        hater
      6. CORE-9816_udfs.reg
        9 kB
        hater
      7. CORE-9816_videotest.iso.bz2
        5.14 MB
        hater
      8. UDF.reg
        9 kB
        Daniel Reimer
      9. udfs_lite.diff
        271 kB
        Pierre Schweitzer
      10. udfs.diff
        399 kB
        Pierre Schweitzer
      11. UDFS.txt
        70 kB
        Daniel Reimer
      1. Image 1.png
        29 kB
      2. ReactOS.png
        21 kB

        Activity

        Hide
        Pierre Schweitzer
        added a comment - - edited

        It's actually even worse with it.

        *** Assertion failed: (((ULONG_PTR)Resource) & (sizeof(ULONG_PTR) - 1)) == 0
        ***   Source File: ../../ntoskrnl/ex/resource.c, line 100
         
        Break repeatedly, break Once, Ignore, terminate Process or terminate Thread (boipt)? 
        kdb:> b
        Execute '.cxr F7549B74' to dump context
         
        Entered debugger on embedded INT3 at 0x0008:0x80944776.
        kdb:> bt
        Eip:
        <NTOSKRNL.EXE:144777 (:0 (DbgBreakPoint))>
        Frames:
        <NTOSKRNL.EXE:36f8e (ntoskrnl/ex/resource.c:100 (ExpVerifyResource))>
        <NTOSKRNL.EXE:389f3 (ntoskrnl/ex/resource.c:1857 (ExReleaseResourceForThreadLite))>
        <udfs.sys:28db3>
        <udfs.sys:2830e>
        <NTOSKRNL.EXE:6f75b (ntoskrnl/io/iomgr/irp.c:1221 (IofCallDriver))>
        <NTOSKRNL.EXE:63c29 (ntoskrnl/io/iomgr/file.c:870 (IopParseDevice))>
        <NTOSKRNL.EXE:f8a9b (ntoskrnl/ob/obname.c:809 (ObpLookupObjectName))>
        <NTOSKRNL.EXE:f170c (ntoskrnl/ob/obhandle.c:2531 (ObOpenObjectByName))>
        <NTOSKRNL.EXE:65080 (ntoskrnl/io/iomgr/file.c:2475 (IoCreateFile))>
        <NTOSKRNL.EXE:6606b (ntoskrnl/io/iomgr/file.c:3421 (NtOpenFile))>
        <NTOSKRNL.EXE:12a084 (ntoskrnl/include/internal/i386/ke.h:706 (KiSystemServiceHandler))>
        <NTOSKRNL.EXE:3da9 (:0 (KiFastCallEntry))>
        <ntdll.dll:c78d>
        <smss.exe:2890>
        <smss.exe:7140>
        <smss.exe:75b1>
        <smss.exe:b64f>
        <smss.exe:bdb6>
        <00000000>
        kdb:> 
        

        Sounds like we've got real differences between our builds...

        Show
        Pierre Schweitzer
        added a comment - - edited It's actually even worse with it. *** Assertion failed: (((ULONG_PTR)Resource) & (sizeof(ULONG_PTR) - 1)) == 0 *** Source File: ../../ntoskrnl/ex/resource.c, line 100   Break repeatedly, break Once, Ignore, terminate Process or terminate Thread (boipt)? kdb:> b Execute '.cxr F7549B74' to dump context   Entered debugger on embedded INT3 at 0x0008:0x80944776. kdb:> bt Eip: <NTOSKRNL.EXE:144777 (:0 (DbgBreakPoint))> Frames: <NTOSKRNL.EXE:36f8e (ntoskrnl/ex/resource.c:100 (ExpVerifyResource))> <NTOSKRNL.EXE:389f3 (ntoskrnl/ex/resource.c:1857 (ExReleaseResourceForThreadLite))> <udfs.sys:28db3> <udfs.sys:2830e> <NTOSKRNL.EXE:6f75b (ntoskrnl/io/iomgr/irp.c:1221 (IofCallDriver))> <NTOSKRNL.EXE:63c29 (ntoskrnl/io/iomgr/file.c:870 (IopParseDevice))> <NTOSKRNL.EXE:f8a9b (ntoskrnl/ob/obname.c:809 (ObpLookupObjectName))> <NTOSKRNL.EXE:f170c (ntoskrnl/ob/obhandle.c:2531 (ObOpenObjectByName))> <NTOSKRNL.EXE:65080 (ntoskrnl/io/iomgr/file.c:2475 (IoCreateFile))> <NTOSKRNL.EXE:6606b (ntoskrnl/io/iomgr/file.c:3421 (NtOpenFile))> <NTOSKRNL.EXE:12a084 (ntoskrnl/include/internal/i386/ke.h:706 (KiSystemServiceHandler))> <NTOSKRNL.EXE:3da9 (:0 (KiFastCallEntry))> <ntdll.dll:c78d> <smss.exe:2890> <smss.exe:7140> <smss.exe:75b1> <smss.exe:b64f> <smss.exe:bdb6> <00000000> kdb:> Sounds like we've got real differences between our builds...
        Hide
        HBelusca
        added a comment -

        I guess it's a problem of structure alignment.

        Show
        HBelusca
        added a comment - I guess it's a problem of structure alignment.
        Hide
        hater
        added a comment - - edited

        It is the same assert from original log in ExReleaseResourceForThreadLite.
        As I mentioned this happens (for me) only if driver is loaded on boot.
        If I make it load on demand and insert iso after boot - it doesn't happen.
        Maybe this release needs some more work?
        It is triggered on media change during boot in UDFVerifyVCB.
        Unfortunately I can't help more on the matter.

        Show
        hater
        added a comment - - edited It is the same assert from original log in ExReleaseResourceForThreadLite . As I mentioned this happens (for me) only if driver is loaded on boot. If I make it load on demand and insert iso after boot - it doesn't happen. Maybe this release needs some more work? It is triggered on media change during boot in UDFVerifyVCB . Unfortunately I can't help more on the matter.
        Hide
        jedi-to-be
        added a comment -

        Ping! Release 0.4.2 is coming. Will it be fixed?

        Show
        jedi-to-be
        added a comment - Ping! Release 0.4.2 is coming. Will it be fixed?
        Hide
        CircularTriangle06
        added a comment -

        strange things seem to be happening with SYSTEM/services/DwUdf/DependOnService value when installing the driver from the package. On XP, it shows zero zero as normal. On ReactOS, it either doesn't appear, or shows something binary.

        Show
        CircularTriangle06
        added a comment - strange things seem to be happening with SYSTEM/services/DwUdf/DependOnService value when installing the driver from the package. On XP, it shows zero zero as normal. On ReactOS, it either doesn't appear, or shows something binary.

          People

          • Assignee:
            Alter
            Reporter:
            Daniel Reimer
          • Votes:
            2 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated: