Official Releases

How feasible would it be to have the map files from an official release 
posted somewhere for download.

This way, when someone complains of a crash from an official release, we 
don't have to walk them through compiling their own copy in order to get 
some map files to look up the error.

Or, am I just going about this the wrong way?

Royce3

VirtualQuery problem

Trying to make unhandled exceptions display the module names for the traced
stack frames (for debug builds), I've stumbled over an error. Since I'm
about to hibernate, perhaps someone else could have a look at it?

The error is as follow:
Module (executable) loaded at usual load addr (0x400000).
VirtualQuery for an address inside this modules mapped address space, say
0x411000, returns a faulty MEMORY_BASIC_INFORMATION.AllocationBase.

I have traced it to MmQuerySectionView in ntoskrnl\mm\section.c, called from
NtQueryVirtualMemory, but there my research ends. The error is that the code
sets both BaseAddress and AllocationBase to the same value. This is wrong.
AllocationBase is to be the first address of the module, i.e. the HMODULE of
it - its load address.

I suspect a call to NtQuerySection or something would be in place, but I
don't really know this area well enough to put the finishing touch to the
correction, why I was hoping someone else might provide some insight or
commit the fix for it.

/Mike

Re: Kernel crash: Timing dependent error on startup

On Fri, Apr 30, 2004 at 11:07:57PM +0200, Mike Nordell wrote:
> Mike Nordell wrote:
> 
> > If you've got a "too fast" machine, the kernel will crash on startup.
> 
> This was wrong, and on closer inspection the user couldn't repro it - at
> least not with a "warm" machine. He's going to test it again sometime later
> and notify. Until then, please disregard everything else I wrote.
> 
The initial process shouldn't exit at all - though the five seconds does
seem arbitary. I think NT has a thread which just waits for the system
process to exit and bug checks if it does.

Re: ReactOS distribution

Which ones are specifically MS Windows(R) download sites?

We do want the Windows crowd opening up to us, after all. - "A Windows clone?!  
For free!?!"

On Thu, 29 Apr 2004 12:30, Stephen Hodges wrote:
> This just occurred to me. Linux is widely available mainly due to the vast
> amount of university and other free software ftp sites. First and foremost,
> GNU.org accepts submissions to their ftp site. That would be a good start.
> Next, there are many other ftp sites, I think sunsite.unc.edu was one of
> them. Making a list and figuring out how to obtain mirrors for downloads
> would be the best way about doing that.
>
> http://www.gnu.org/home.html#directory<http://www.gnu.org/home.html#directo
>ry>
>
>
> More publicity can be obtained when security flaws begin to show up, by
> posting the finds to BugTraq and securityfocus, and possibly others.

--

-- 
Wesley Parish
* * *
Clinersterton beademung - in all of love.  RIP James Blish
* * *
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."

Re: ReactOS distribution

On Wed, Apr 28, 2004 at 08:30:27PM -0400, Stephen Hodges wrote:
> This just occurred to me. Linux is widely available mainly due to the vast amount of university and other
free software ftp sites.

Well, i think the way to go might be bittorrent. It sure looks like the
way for the future to me (well, not really bittorrent, because it has
some major flaws, but such a system anyways). If we do that i think we
have several people who can 'support' the torrents by seeding.

Mark

Re: USB driver

On Thursday 29 April 2004 01:23, Stephen Hodges wrote:
> Here's the start of a USB 2.0 Hub & device driver. There is still much to
> be done.

Hi!

I would say there is *a lot* to be done in this area. USB was made to be 
simple for the end-user, not simple for the developer. Have you ever written 
some kind of USB driver? I was once reading a bit of the specs and i think 
you should first check how USB is interfaced in windows, then make some plans 
and then start coding ;)
Or do you already have any plans/flowcharts/whatever? If so please let us see 
them :)

Maybe I can help a bit with USB (altough the server side is really complicated 
afaik)

 - blight

RE: VirtualQuery problem

> -----Original Message-----
> From: ros-kernel-bounces@... 
> [mailto:ros-kernel-bounces@...] On Behalf Of Mike Nordell
> Sent: Saturday, May 01, 2004 9:24 AM
> To: ros-kernel
> Subject: [ros-kernel] VirtualQuery problem
> 
> 
> I have traced it to MmQuerySectionView in 
> ntoskrnl\mm\section.c, called from NtQueryVirtualMemory, but 
> there my research ends. The error is that the code sets both 
> BaseAddress and AllocationBase to the same value. This is 
> wrong. AllocationBase is to be the first address of the 
> module, i.e. the HMODULE of it - its load address.
> 
> I suspect a call to NtQuerySection or something would be in 
> place, but I don't really know this area well enough to put 
> the finishing touch to the correction, why I was hoping 
> someone else might provide some insight or commit the fix for it.

MmQuerySectionView should handle image sections in a different way. 

- Hartmut

_______________________________________________
Ros-kernel mailing list

Re: Kernel crash: Timing dependent error on startup

At 10.35 01/05/2004, you wrote:
>The initial process shouldn't exit at all - though the five seconds does 
>seem arbitary. I think NT has a thread which just waits for the system 
>process to exit and bug checks if it does.

nope, you can happily kill SMSS, nobody keeps track of it nor will care 
(except it's also the debugging subystem in Windows 2000 and earlier, so 
something actually breaks). It's SMSS that displays the BSOD (*not* a 
bugcheck, just a kernel-only shutdown that ends in a BSOD, started with 
NtRaiseHardError) when winlogon or CSRSS terminate 

Re: VirtualQuery problem

Hartmut Birr provided a patch with the following words of wisdom:

> MmQuerySectionView should handle image sections in a different way.

Works like a charm. Committed.

/Mike

Kernel Debugger doesn't correctly identify all types of calls

Hi!

Today I have tested KDB a bit and it works well but I have seen it 
stepping over indirect calls like the following code:
FF 15 F4 68 87 69

This is the code which is checking wether the current instruction is a 
call to decide wether to step over it (break after the instruction and 
continue) or single-step:

  /* Check if the current instruction is a call. */
  while (Eip[0] == 0x66 || Eip[0] == 0x67)
  {
    Eip++;
  }
  if (Eip[0] == 0xE8 || Eip[0] == 0x9A || Eip[0] == 0xF2 || Eip[0] == 
0xF3 ||
      (Eip[0] == 0xFF && (Eip[1] & 0x3C) == 0x10))
  ...

Reading the Intel instruction reference I found out that 0xFF is the 
primary opcode,
0x15 is the ModR/M byte and F4 68 87 69 is the address (0x698768F4)
The ModR/M byte consists of the following parts:
bits 0..2  R/M
bits 3..5 Opcode/Reg
bits 6..7 Mod

 From the Intel Manual: "The mod field combines with the r/m field to 
form 32 possible values: eight registers and