Hi!
Could someone who is building ReactOS on a Linuy system have a look at
why mkhive fails when Live-CD is built? Unfortunately I don't have a
Linux system for testing.
Thanks in advance!
Eric
This bug is a lot older than that, I can't remember thread list ever not being crash-prone.
From 0.3.11 livecd:
←[7h♣Entered debugger on embedded INT3 at 0x0008:0x808c6fb6.
kdb:> proc list
PID State Filename
*0x00000004 In Memory System
0x00000044 In Memory smss.exe
0x0000007c In Memory csrss.exe
0x000000a0 In Memory winlogon.exe
0x000000bc In Memory services.exe
0x000000c4 In Memory lsass.exe
0x000000f0 In Memory eventlog.exe
0x0000010c In Memory spoolsv.exe
0x00000120 In Memory dhcp.exe
0x0000013c In Memory rpcss.exe
0x00000180 In Memory umpnpmgr.exe
0x00000290 In Memory explorer.exe
kdb:> proc attach 0xa0
Attached to process 0x000000a0, thread 0x000000a4.
kdb:> thread list
TID State Prior. Affinity EBP EIP
*0x000000a4 Waiting 8 0x00000001 0x0063fecc 0x7c90697a
Assertion 'TempPte.u.Long != 0' failed at ARM┬│::PAGFAULT line 161
Entered debugger on embedded INT3 at 0x0008:0x808c6fb6.
*** Fatal System Error: 0x0000001e
(0x80000003,0x808C6FB6,0x80957048,0x00000000)
Entered debugger on embedded INT3 at 0x0008:0x808c6fbc.
Revision 46042:
[KERNEL32/CSRSS]: Register new Win32 threads with CSRSS. Add a bunch of
lookup, creation, allocation, hashing and CSR thread management routines
from the unused CSRSRV in trunk.
[CSRSS]: Bang in the new thread support in a bunch of places, including
creating static server threads. It's very hacked and handle duplication
doesn't work 100% reliably, but it gets the job done.
[CSRSS]: Add CsrGetProcessLuid, CsrImpersonateClient, CsrRevertToSelf,
CsrShutdownProcesses, CsrFindProcessForShutdown required for user-mode
shutdown. Right now we are able to reliably enumerate user apps (in the user
LUID) and then service/system apps (in the LOCAL SYSTEM LUID).
triggers regression described here:
http://www.reactos.org/bugzilla/show_bug.cgi?id=5318
(KDBG: Thread list command ASSERTs after attaching to process with PID A0 or
higher)
Hi,
After this commit ac97 doesn't install anymore, device wizard remains in a loop and the debug log shows:
(drivers/wdm/audio/filters/kmixer/kmixer.c:99) KMixer.sys loaded
(drivers/wdm/audio/filters/kmixer/kmixer.c:48) KMix_InstallDevice called
(drivers/wdm/audio/filters/kmixer/kmixer.c:83) KMix_InstallDevice result 0
(ntoskrnl/io/pnpmgr/pnpmgr.c:202) Warning: Starting a device node without DNF_ADDED
Thanks.
Gabriel.
> Date: Wed, 21 Apr 2010 14:06:01 +0000
> To: ros-diffs(a)reactos.org
> From: sir_richard(a)svn.reactos.org
> Subject: [ros-diffs] [sir_richard] 46977: [NTOS]: Enable MmPageEntireDriver by implementing MiSetPagingOfDriver. [NTOS]: Call MiEnablePagingOfDriver from MmLoadSystemImage and implement it. All the work is done other than actually enabling paging, which requires system working set support. [NTOS]: Implement MiWriteProtectSystemImage and MiComputeDriverProtection. All the work is done other than actually setting the bits on the pages, since I wanted to avoid too many changes. [NTOS]: MmCheckSystemImage returns STATUS_INVALID_IMAGE_PROTECT, not STATUS_INVALID_IMAGE_FORMAT, so the branch in MmLoadSystemImage needs to check for the correct status code. [NTOS]: Support FLG_SHOW_LDR_SNAPS for the kernel loader.
>
_________________________________________________________________
Messenger e Hotmail in tasca. Provali sul tuo cellulare!
http://new.windowslivemobile.msn.com/it-it/Default.aspx
Not surprised!
I guess ReactOS new polices are for hiding the real issues and not
fixing them and revert all the correct code. Since the kernel rewrites
and the new order of coding, these oddities have now surfaced. The
TEB, is inaccessible from kernel mode as in bug 5265 and 5314, and the
strange processes access issues in bug 5310. This revert silliness
will result in moving the project back to post windows 95 architecture
(arwinss). ReactOS is about moving forward and taking chances with
innovations from learned information then moving away to make it work
even better. Personally, I hope someone will take up where this left
off and move on.
Good luck!
Reference:
http://www.reactos.org/bugzilla/show_bug.cgi?id=5265http://www.reactos.org/bugzilla/show_bug.cgi?id=5310http://www.reactos.org/bugzilla/show_bug.cgi?id=5314
Gregor Schneider <grschneider(a)gmail.com> wrote:
> That made me think: what happens to this field if the ShellExecuteEx
> call succeeds and the flag SEE_MASK_NOCLOSEPROCESS is not set? Since
> this check was thought to forward the actual result of the execution i
> switched to a simpler and (in my eyes) more reliable code. Plus the
> original code did not use the flag noted in the specification.
> The link you provided on the other hand makes it look like
> ShellExecuteEx always sets this field indendent of any flags passed to
> the function.
>
> To find out the truth one would have to write test cases. It might
> well be that the implementation we use is partially incorrect.
> Especially when looking at testman (it works again :-O ) @
> shell32_winetest shlexec which still has some failures.
Hi Greg,
Perhaps You already know, but let's spell it out anyway:
hInstApp inherits it's traits from WinExec and LoadModule.
WinExec used to be declared HINSTANCE WinExec( LPCSTR CmdLine, UINT
CmdShow ),
and LoadModule also returned a HINSTANCE. At that time they did return
the instance handle, i.e the load address, and it was safe to use these
low values as error codes, because they were impossible load addresses
(they still are).
Even though WinExec/LoadModule's signatures have changed, and we've
been given CreateProcess to exert better control, somewhere in the bowels
of Microsoft's code I'm convinced it still percolates down to basically the
same code to load/launch a module, so the traits remain. And since the
shell APIs are mostly just alternate wrappings for standard Win32 APIs,
it percolates to there as well.
I don't think we need to bother with test cases for this, we could
apply some common sense instead. A quick test shows that both
WinExec and LoadModule actually just return 33 when they succeed,
so we could(/should?) let hInstApp always reflect load status the same
way that WinExec/LoadModule does, regardless of the flags.
That's the most polite to users of ShellExecuteEx.
Then they can error branch on either one.
In case of doubt, always wear both belt and suspenders ;)
if (ShellExecuteExW( &sei ) == FALSE)
return E_FAIL;
if ((INT) sei.hInstApp <= 32)
return E_UNEXPECTED;
Best Regards
// Love
victor martinez <vicmarcal(a)hotmail.com <mailto:vicmarcal@hotmail.com>>
wrote:
>
> - if (sei.hInstApp <= (HINSTANCE)32)
> + if ((INT)sei.hInstApp <= 32)
>
> As you see i am just learning, so thanks in advance.
>
To enlighten You:
If you look at the assembly listing, You'll see that those
two variants generate exactly the same code.
Best Regards
// Love
Hi Jim,
Please don't take this personal, the code has been #iffed out not reverted.
I agree with you that we should keep good code, problem is that lately someone introduces a regression with new or modified code (even correct),
and the regression stays there forever, we should try to avoid such a case.
In this specific case we know the gdibatch code introduced that regression, so my suggestion is: do the commit anyway with a specific roadmap to fix the regression or disable it temporary until the regression is fixed.
Perception is really important, what's gonna think about ros someone that tried it before, now after a new release tries it again and sees that what was working before doesn't work anymore or works worse than it did, your references are a good example of this scenario, but see also:
4461 Regression: Notepad Lite doesn't install
4677 Regression: Can't restore minimized windows
4948 Regression: Can't close locale dialog
5276 Regression: shell about dialog doesn't display header bitmap
And there are more...
I'm not gonna blame win32k only here as regressions are not its exclusivity, it's funny that before uniata we were suggesting people to rename uniata to atapi to test in boxes with sata controllers, now we do the oposite (atapi -> uniata )to let people test in pata.
I've mentioned in ros-dev also that ros takes more than 2 minutes in my virtual machine to install when it tooks some seconds before (two hd attached to the primary channel), I'm not able to test ros so frequently now because of this.
I've also mentioned that AC97 stopped working, has regressed for several reasons several revisions away, now I'm not being prompted anymore for its driver as 46998...
We can't keep working like this, testers should work in a coordinated way with developers, both of them are important, there aren't many skilled testers to be honest just take a look at bugzilla...
Sometimes I test and see regressions and don't know what to do anymore, stop testing, tell ros-dev, bug the dev, give up...
Gabriel.
> Date: Thu, 22 Apr 2010 20:47:52 -0500
> From: jimtabor.rosdev(a)gmail.com
> To: ros-dev(a)reactos.org
> Subject: [ros-dev] [ros-diffs] [tkreuzer] 46998: Disable gdi batch for SelectObject with fonts. Fixes font regression.
>
> Not surprised!
>
> I guess ReactOS new polices are for hiding the real issues and not
> fixing them and revert all the correct code. Since the kernel rewrites
> and the new order of coding, these oddities have now surfaced. The
> TEB, is inaccessible from kernel mode as in bug 5265 and 5314, and the
> strange processes access issues in bug 5310. This revert silliness
> will result in moving the project back to post windows 95 architecture
> (arwinss). ReactOS is about moving forward and taking chances with
> innovations from learned information then moving away to make it work
> even better. Personally, I hope someone will take up where this left
> off and move on.
>
> Good luck!
>
> Reference:
>
> http://www.reactos.org/bugzilla/show_bug.cgi?id=5265
> http://www.reactos.org/bugzilla/show_bug.cgi?id=5310
> http://www.reactos.org/bugzilla/show_bug.cgi?id=5314
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
_________________________________________________________________
Messenger e Hotmail in tasca. Provali sul tuo cellulare!
http://new.windowslivemobile.msn.com/it-it/Default.aspx
Isn't that just a audio driver regression not an Install wizard one?
"Starting a device node without DNF_ADDED"
On 22 April 2010 14:09, Gabriel ilardi <gabrielilardi(a)hotmail.it> wrote:
> Hi,
> Device installation wizard has regressed again, now if you try to install
> the AC97 driver, it remains in a loop, and ros slows down at the point of
> being unusabe,
> the debug log shows:
>
> (ntoskrnl/io/pnpmgr/pnpmgr.c:190) Warning: Starting a device node without
> DNF_ADDED or DNF_ENUMERATED (Root\LEGACY_kmixer\0000)
>
> Thanks,
>
> Gabriel.
>
> > Date: Wed, 21 Apr 2010 22:33:12 +0000
> > To: ros-diffs(a)reactos.org
> > From: cgutman(a)svn.reactos.org
> > Subject: [ros-diffs] [cgutman] 46983: [NTOSKRNL] - Replace the broken
> CM_RESOURCE_LIST_SIZE with a better function that actually works with
> resource lists that have device-specific data in them (fixes missing device
> specific data when resources are retrieved with IoGetDeviceProperty) -
> Separate the resource code out of pnpmgr.c and into pnpres.c - Simplify
> resource assigning to simply calling one function, IopAssignDeviceResources,
> which takes care of the registry configuration, translation, etc. - Set the
> DNF_NEED_ENUMERATION_ONLY flag only AFTER the device is actually started not
> before - Set DNF_START_FAILED if IRP_MN_START_DEVICE fails - Fix a bug in
> IoReportDetectedDevice that wrote the AllocConfig value to wrong place
> >
> > Author: cgutman
> > Date: Thu Apr 22 00:33:11 2010
> > New Revision: 46983
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=46983&view=rev
> > Log:
> > [NTOSKRNL]
> > - Replace the broken CM_RESOURCE_LIST_SIZE with a better function that
> actually works with resource lists that have device-specific data in them
> (fixes missing device specific data when resources are retrieved with
> IoGetDeviceProperty)
> > - Separate the resource code out of pnpmgr.c and into pnpres.c
> > - Simplify resource assigning to simply calling one function,
> IopAssignDeviceResources, which takes care of the registry configuration,
> translation, etc.
> > - Set the DNF_NEED_ENUMERATION_ONLY flag only AFTER the device is
> actually started not before
> > - Set DNF_START_FAILED if IRP_MN_START_DEVICE fails
> > - Fix a bug in IoReportDetectedDevice that wrote the AllocConfig value to
> wrong place
> >
> > Added:
> > trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.c (with props)
> > Modified:
> > trunk/reactos/ntoskrnl/include/internal/io.h
> > trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c
> > trunk/reactos/ntoskrnl/io/pnpmgr/pnpreport.c
> > trunk/reactos/ntoskrnl/ntoskrnl-generic.rbuild
>
> ------------------------------
> Condividi le tue emozioni e proteggi la tua privacy. Chiacchiera su
> Messenger <http://www.windowslive.it/importaAmici.aspx>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--
Andrew Faulds (andrewros)
http://ajf.me/
After asking in ReactOS-dev what is the antonym of "Regression" (thanks DosX for telling me :) ), I am glad to show you an "IMPROVEMENT".
It´s easy to complain about Regressions but we should try to show our little improvements.
Congrats to our Devs because their efforts :)
== Foxit Reader 2.1 is much more usable. 0.3.11 screenshot vs Trunk screenshot.==
Screenshot: http://img696.imageshack.us/img696/8839/foxit2.jpg
_________________________________________________________________
Tus datos personales, más seguros con Internet Explorer 8.
http://www.microsoft.com/spain/windows/internet-explorer/default.aspx
Hi,
Device installation wizard has regressed again, now if you try to install the AC97 driver, it remains in a loop, and ros slows down at the point of being unusabe,
the debug log shows:
(ntoskrnl/io/pnpmgr/pnpmgr.c:190) Warning: Starting a device node without DNF_ADDED or DNF_ENUMERATED (Root\LEGACY_kmixer\0000)
Thanks,
Gabriel.
> Date: Wed, 21 Apr 2010 22:33:12 +0000
> To: ros-diffs(a)reactos.org
> From: cgutman(a)svn.reactos.org
> Subject: [ros-diffs] [cgutman] 46983: [NTOSKRNL] - Replace the broken CM_RESOURCE_LIST_SIZE with a better function that actually works with resource lists that have device-specific data in them (fixes missing device specific data when resources are retrieved with IoGetDeviceProperty) - Separate the resource code out of pnpmgr.c and into pnpres.c - Simplify resource assigning to simply calling one function, IopAssignDeviceResources, which takes care of the registry configuration, translation, etc. - Set the DNF_NEED_ENUMERATION_ONLY flag only AFTER the device is actually started not before - Set DNF_START_FAILED if IRP_MN_START_DEVICE fails - Fix a bug in IoReportDetectedDevice that wrote the AllocConfig value to wrong place
>
> Author: cgutman
> Date: Thu Apr 22 00:33:11 2010
> New Revision: 46983
>
> URL: http://svn.reactos.org/svn/reactos?rev=46983&view=rev
> Log:
> [NTOSKRNL]
> - Replace the broken CM_RESOURCE_LIST_SIZE with a better function that actually works with resource lists that have device-specific data in them (fixes missing device specific data when resources are retrieved with IoGetDeviceProperty)
> - Separate the resource code out of pnpmgr.c and into pnpres.c
> - Simplify resource assigning to simply calling one function, IopAssignDeviceResources, which takes care of the registry configuration, translation, etc.
> - Set the DNF_NEED_ENUMERATION_ONLY flag only AFTER the device is actually started not before
> - Set DNF_START_FAILED if IRP_MN_START_DEVICE fails
> - Fix a bug in IoReportDetectedDevice that wrote the AllocConfig value to wrong place
>
> Added:
> trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.c (with props)
> Modified:
> trunk/reactos/ntoskrnl/include/internal/io.h
> trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c
> trunk/reactos/ntoskrnl/io/pnpmgr/pnpreport.c
> trunk/reactos/ntoskrnl/ntoskrnl-generic.rbuild
_________________________________________________________________
Messenger e Hotmail in tasca. Provali sul tuo cellulare!
http://new.windowslivemobile.msn.com/it-it/Default.aspx