Howdy,
I recently encountered an assert while testing with the Checked Vista kernel
for 32bit x86. Unfortunately, Vista Checked builds no longer print the
reason for their assertions. I examined the disassembly and tried different
parameters (the ones that it seemed to be asserting on), but no luck.
Perhaps you would be kind enough to tell me the reason for the following
assert?

If you have your symbol and source servers setup, I bet you could just do:
WinDBG >> File >> Open >> Crash Dump >>
"\WinDDK\6000\debug\i386\ntkrpamp.exe" >> "0:000> lsa
ntkrpamp!MmMapIoSpace+0x2f3"

My WinDBG Output:
Assertion failure - code c0000420 (first chance)
nt!MmMapIoSpace+0x2f3:
81878ced cd2c int 2Ch

lm m nt //condensed
Timestamp: Thu Nov 02 02:29:39 2006 (4549AC73)
File flags: 1 (Mask 3F) Debug
File OS: 40004 NT Win32
FileVersion: 6.0.6000.16386 (vista_rtm.061101-2205)

This happens after a map, unmap, and then an attempt to map a subsection of
the region previously mapped (always as MmNonCached). This code does not
assert in Windows 2000 or XP Checked. The virtual address returned seems to
work flawlessly, and it is working without failure on many test systems.
However, we would like to know the reason for the assert so that we may
consider our options.

I also noticed that Drew Bliss [MSFT] told Don Burn that these assert
messages would be made available in the future (see "Future suggestion",
09/28/2006). I fully support this idea!

Thank you,
--
Jeremiah
National Instruments -- http://www.ni.com

"stack smasher" djajadi tribute.

This is the assert statement:

((Pfn1->u3.e2.ReferenceCount != 0) ||
(Pfn1->u3.e1.Rom == 1) && (CacheType == MmCached))

Can you dump the PFN it complains about with the !pfn
command? The address of the PFN seems to be at eax-0x10
(you can verify this by checking disassembly).

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

"Jeremiah" wrote:

Both Pavel and I requested our engineer in charge of NT memory manager to
throw some insight into this. This is what he had to say:

This assert means that he is mapping a regular memory address (ie, not dual
port I/O space memory, etc), and that this regular memory address is *NOT*
locked down.

This is very bad because it means the caller does not "own" the page and
that the page can be changing states (ie, it can be allocated, freed,
reallocated, etc). As part of the state changing, each new owner can assign
new cache attributes to it (ie, allocate it noncached or cached or
writecombined, etc), and the new attribute can easily conflict with the one
the caller is currently intending to use.

And attribute conflicts are strictly forbidden by the CPU manufacturers (can
cause "undefined" behavior) as well as data corruption, system hangs, etc.

You will definitely want to have this guy fix his code.

-Eliyas

Eliyas,

We need to be able to inspect this memory for malicious content. I don't
have a problem with a debug assertion in checked builds. But going beyond
that would create a problem.

Regards,

Rossetoecioccolato.

"Eliyas Yakub [MSFT]" <eliyasy@online.microsoft.com> wrote in message
news:uyF98KNOHHA.3944@TK2MSFTNGP06.phx.gbl...