Physical memory access wanted
Pat LaVarre
> > > Windows 2000 and interface to it (C header
> > > file) to provide access to physical memory.
> >
> > Take a look at http://www.sysinternals.com/tips.htm#KMem
> > They've a little program (with source code) for d/l
> > that displays the physical memory using the
> > "PhysicalMemory" device.
>
> From: Pavel A. (pav...@my-deja.com)
> Subject: Re: Physical memory access wanted
> Date: 2000/02/29
>
> PHYSMEM doesn't (quite) seem to work on win2k.2195.
>
> It opens the mapping and reads with no error
> messages - but dumps garbage.
> At 0x1000 - nothing like the sample output at the
> URL above.
Me too. I get mostly zeroes.
> Dumping ROM of my device at 0EC000 - bummer. Garbage again.
Yes.
> I'll try to recompile PHYSMEM, but have a hunch it won't help.
I tried the recompile. MinGW gcc. No joy. MSVC 6. No joy.
> no visible error or exception occurs.
I get no error/exception at address x1000.
But if I try out in PCI space I see: The parameter is incorrect.
Pat LaVarre
P.S. Google may append this post to the thread that some think ended
with:
http://groups.google.com/groups?as_umsgid=%3C89hh1a%24fe0%241%40nnrp1.deja.com%3E%231%2F1
P.P.S. Quoting more fully, specifically I see:
Physmem v1.0: physical memory viewer
By Mark Russinovich
Systems Internals - http://www.sysinternals.com
Enter values in hexadecimal. Enter 'q' to quit.
Address: 1000
Bytes: 1000
00001000: 00 00 00 00 00 00 00 00 -00 00 00 00 00 00 00 00 ...
00001010: 00 00 00 00 00 00 00 00 -00 00 00 00 00 00 00 00 ...
00001020: 00 00 00 00 00 00 00 00 -00 00 00 00 00 00 00 00 ...
...
Address: D4100000
Bytes:
Could not map view of D4100000 length 1000: The parameter is
incorrect.
...
Address: q
James Antognini
physical memory views. The PhysMem sample fails here:
ntStatus = NtMapViewOfSection (PhysicalMemory,
(HANDLE) -1,
(PVOID) VirtualAddress,
0L,
*Length,
&viewBase,
Length,
ViewShare,
0,
PAGE_READONLY );
The status code is 0xc0000018, which means STATUS_CONFLICTING_ADDRESSES.
I believe this return code is the result of Microsoft tightening up some
interfaces. (Do a search on STATUS_CONFLICTING_ADDRESSES. You'll get,
for example, "Specifying PAGE_NOCACHE when mappping
\Device\PhysicalMemory (fyi) ," by Eliyas Yakub, on 19 July 2001, in
this very newsgroup.)
I've had fairly good luck mapping physical memory via
ZwMapViewOfSection() in kernel mode. See, for example, GetMemory.cpp in
RealModeDriver.zip at http://home.mindspring.com/~antognini/drivers/.
But I have to warn you that using ZwMapViewOfSection() is quite tricky,
because it's poorly documented.
--
If replying by e-mail, please remove "nospam." from the address.
James Antognini
Pat LaVarre
> Date: 2003-04-03 17:39:27 PST
Thanks for L" and OBJ_CASE_INSENSITIVE, both new to me.
> Subject: Re: sample W2K PCI driver for memory mapped I/O
> From: Maxim S. Shatskih (ma...@storagecraft.com)
> Date: 2003-04-03 13:27:46 PST
Thanks for pointing me to ZwOpenSection. Play by play, my experience
is:
Try 1:
... : fatal error C1083 : Cannot open include file: 'ntddk.h': No such
file or directory.
Try 2:
...\ntddk.h(23) : fatal error C1189: #error : Compiler version not
supported by Windows DDK
Try 3:
#undef _MSC_VER
#define _MSC_VER 9999
...
... : fatal error C1003: error count exceeds 100: stopping compilation
Try 4:
Copy what I need from ntddk.h etc., just as physmem does.
More soon, thanks again for the fruitful tips. I'm hoping I've been
told I can call ZwOpenSection from a root-privileged user app, I am
now trying ...
Pat LaVarre
James Antognini
going to have a hard time if you're trying another way to build.
Pat LaVarre
> From: James Antognini (anto...@mindspring.nospam.com)
> Date: 2003-04-03 17:39:27 PST
Thanks for ZwClose, MSDN neglects to link to there from ZwOpenSection.
> > play by play
> >
> > Copy what I need from ntddk.h etc.,
> > just as physmem does ...
MinGW gcc and MSVC fail to link in seemingly analogous ways.
For MinGW I had to write:
#ifndef NTSYSAPI
From MSVC:
error LNK2001: unresolved external symbol "__declspec(dllimport) long __stdcall
ZwClose(void *)" (__imp_?ZwClose@@YGJPAX@Z)
error LNK2001: unresolved external symbol "__declspec(dllimport) long __stdcall
ZwOpenSection(void * *,unsigned long,struct _OBJECT_ATTRIBUTES *)"
(__imp_?ZwOpenSection@@YGJPAPAXKPAU_OBJECT_ATTRIBUTES@@@Z)
error LNK2001: unresolved external symbol "__declspec(dllimport) void __stdcall
RtlInitUnicodeString(struct _UNICODE_STRING *,unsigned short const *)"
(__imp_?RtlInitUnicodeString@@YGXPAU_UNICODE_STRING@@PBG@Z)
I got my UNICODE_STRING from the October 2001 MSDN Library UNICODE_STRING
entry.
I got my NTSTATUS OBJECT_ATTRIBUTES POBJECT_ATTRIBUTES
InitializeObjectAttributes from winddk/3615/inc/wxp/ntdef.h
I got my STATUS_SUCCESS from winddk/3615/inc/ddk/wxp/ntstatus.h
I got my OBJ_CASE_INSENSITIVE OBJ_KERNEL_HANDLE RtlInitUnicodeString
ZwOpenSection ZwClose from winddk/3615/inc/ddk/wxp/ntddk.h
Pat LaVarre
Maxim S. Shatskih
>
> error LNK2001: unresolved external symbol "__declspec(dllimport)
long __stdcall
> ZwClose(void *)" (__imp_?ZwClose@@YGJPAX@Z)
Wrap NTDDK.H to
extern "C"
{
}
construct. MS did not bother to make this header compatible with C++,
at least on pre-XP DDKs.
Max
Pat LaVarre
> Wrap NTDDK.H to ... extern "C" ... { ... }
Sorry to report no joy.
Try 1:
... : fatal error C1083 : Cannot open include file: 'ntddk.h': No such
file or directory.
Try 2:
...\ntddk.h(23) : fatal error C1189: #error : Compiler version not
supported by Windows DDK
Pat LaVarre
P.S. I tried both .c and .cpp as my main source file.
Pat LaVarre
> Date: 2003-04-04 14:02:43 PST
> Wrap NTDDK.H to ... extern "C" ... { ... }
Ah, whoops, I'm now thinking I should also have tried extern "C" { } of my own
.h of fragments copied from MSDN and the WINDDK. Please stay tuned ...
Pat LaVarre
Pat LaVarre
> Date: 2003-04-04 14:02:43 PST
> Wrap NTDDK.H to ... extern "C" ... { ... }
Inserting extern "C" into my own header of fragments changes the form of my
"error LNK2001"s to say my "unresolved external symbol"s now are:
__imp__ZwClose@4
__imp__ZwOpenSection@12
__imp__RtlInitUnicodeString@8
Is this progress?
Cluelessly, curiously, thankfully yours, Pat LaVarre
Pat LaVarre
HREF="mailto:anto...@mindspring.nospam.com">anto...@mindspring.nospam.
com</A>
> Date: Fri, Apr 4, 2003 10:52 am
> It looks as though you are
> not using the standard DDK build.
Is there a compile-and-link command line I should try inside the "Win XP Free
Build Environment" of my DDK?
Something analogous to Linux `g++ -Wall -o wmmap wmmap.cpp`, in case you know
that command line?
Pat LaVarre
Pat LaVarre
> Date: Sat, Apr 5, 2003 9:27 am
> Is there a compile-and-link command line I should
> try inside the "Win XP Free Build Environment" of
> my DDK?
In that new context:
cl /Wall /IC:\WINDDK\3615\inc\ddk\wxp wmmap.cpp
looks like progress. Now I die with:
fatal error C1083: Cannot open include file: 'excpt.h': No such file or
directory
Pat LaVarre
Maxim S. Shatskih
Max
"Pat LaVarre" <ppa...@aol.com> wrote in message
news:20030405112328...@mb-fp.aol.com...
Alexander Grigoriev
"Pat LaVarre" <ppa...@aol.com> wrote in message
news:20030405111817...@mb-fp.aol.com...
Pat LaVarre
> > I use to talk slowly to the [memory-mapped i/o of my one-off
> > custom PCI] card.
...
> From: "Maxim S. Shatskih" ma...@storagecraft.com
> Date: Sat, Apr 5, 2003 11:45 am
> Are you trying to include NTDDK.H to _user mode_ project?
Yes.
I moved further down this road, when I saw you write
"MmMapLockedPages(...UserMode...) in a driver, or open \Device\PhysicalMemory
by ZwOpenSection and then call ZwMapViewOfSection".
Did you mean to say both of those techniques work inside drivers only?
I mean to be asking only about techniques that work inside .exe's that can be
called as easily as, for example, C:/Windows/System32/Find.exe
Personally I'm stunningly vague on Win jargon. In Unix jargon I'd say those
are "user apps". I'm thinking in Win Jargon I say those are "_user mode_
project"s.
Alexander Grigoriev
DDK docs/Driver Developments Tools/The Build Utility/Build Utility
Reference/sources File
The problem is you you need very exact compilation/link options set (which
can change with the next DDK release, etc). BUILD does it all for you, as
long as you provide a SOURCES file.
Here is a template SOURCES file:
#
# The developer defines the TARGETNAME variable. It is the name of
# the target (component) that is being built by this makefile.
# It should not include any path or filename extension.
#
TARGETNAME=xxxxx
#
# The developer defines the TARGETPATH and TARGETTYPE variables.
# The first variable specifies where the target will be built. The second
specifies
# the type of target (either PROGRAM, DYNLINK, LIBRARY, UMAPPL_NOLIB or
# BOOTPGM). Use UMAPPL_NOLIB when you are only building user-mode
# programs and do not need to build a library.
#
TARGETPATH=obj
# Select one of the following, and delete the others:
TARGETTYPE=PROGRAM
TARGETTYPE=DYNLINK
TARGETTYPE=LIBRARY
TARGETTYPE=UMAPPL_NOLIB
TARGETTYPE=BOOTPGM
TARGETTYPE=DRIVER
TARGETTYPE=DRIVER_LIBRARY
TARGETTYPE=EXPORT_DRIVER
TARGETTYPE=GDI_DRIVER
TARGETTYPE=MINIPORT
TARGETTYPE=NOTARGET
TARGETTYPE=PROGLIB#
# If your TARGETTYPE is DRIVER, you can optionally specify DRIVERTYPE.
# If you are building a WDM Driver, use DRIVERTYPE=WDM, if you are building
# a VxD use DRIVERTYPE=VXD. Otherwise, delete the following two lines.
#
DRIVERTYPE=WDM
DRIVERTYPE=VXD
#
# The TARGETLIBS macro specifies additional libraries to link against your
target
# image. Each library path specification should contain an asterisk (*)
# where the machine-specific subdirectory name should go.
#
TARGETLIBS=
#
# The INCLUDES variable specifies any include paths that are specific to
# this source directory. Separate multiple paths with single
# semicolons. Relative path specifications are okay.
#
INCLUDES=..\inc
#
# The developer defines the SOURCES macro. It contains a list of all the
# source files for this component. Specify each source file on a separate
# line using the line-continuation character. This minimizes merge
# conflicts if two developers are adding source files to the same component.
#
SOURCES=source1.c \
source2.c \
source3.c \
source4.c
i386_SOURCES=i386\source1.asm
IA64_SOURCES=ia64\source1.s
#
# Next, specify options for the compiler using C_DEFINES.
# All parameters specified here will be passed to both the C
# compiler and the resource compiler.
C_DEFINES=
#
# Next, specify one or more user-mode test programs and their type.
# Use UMTEST for optional test programs. Use UMAPPL for
# programs that are always built when the directory is built. See also
# UMTYPE, UMBASE, and UMLIBS. If you are building a driver, the next
# 5 lines should be deleted.
#
UMTYPE=nt
UMTEST=bunny*baz
UMAPPL=bunny*baz
UMBASE=0x1000000
UMLIBS=obj\*\bunny.lib
#
# Defining either (or both) the variables NTTARGETFILE0 and/or NTTARGETFILES
# causes makefile.def to include .\makefile.inc immediately after it
# specifies the top level targets (all, clean and loc) and their
dependencies.
# The makefile.def file expands NTTARGETFILE0 as the first dependent for the
# "all" target and NTTARGETFILES as the last dependent for the "all" target.
# This is useful for specifying additional targets and dependencies that do
not fit the
# general case covered by makefile.def.
#
# NTTARGETFILE0=
# NTTARGETFILES=
"Pat LaVarre" <ppa...@aol.com> wrote in message
news:20030405112703...@mb-fp.aol.com...
Pat LaVarre
> Date: Sat, Apr 5, 2003 12:21 pm
> using DDK BUILD, after all?
> It looks like you don't.
I am.
But I'm Not Only trying that. I'm trying every Win cc I can find. I tried
MinGW gcc. I tried Start --> All Programs --> Microsoft Visual Studio 6.0 ->
Microsoft Visual C++ 6.0. Now I'm trying Start --> All Programs -->
Development Kits --> Windows DDK 3615 --> Build Environments --> Windows XP -->
Win XP Free Build Environment.
That last choice landed me in C:\WINDDK\3615. I answered "START ." and then
clicked about. In bin/x86/ I found cl.exe. Turns out that folder is first in
my PATH.
The command `cl` tells me there I have found:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9176 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
But now I think Maxim S is telling me I'm trying to build the wrong code. I
think Maxim S says we've been telling me how to teach a driver to touch
whatever memory-mapped i/o it likes.
I mean to be asking how to let ME interact with hardware, not how I can build
some canned daemon program I'd run without a human interface.
Is the trouble here that "everyone knows" that in Windows there is no analogous
to Linux "/dev/mem"? I have to learn to write a driver, and how to share
memory between that driver and my user app?
And no canned examples of this appear anywhere on the web??? (Or in the DDK,
or in MSDN?)
Pat LaVarre
> Date: Sat, Apr 5, 2003 12:28 pm
...
> The problem is you you need very exact compilation/link options set
> (which can change with the next DDK release, etc).
> See:
> DDK docs/
> Driver Developments Tools/The Build Utility/Build Utility Reference/sources
File
With this I can sync, thank you.
I found Start --> All Programs --> Development Kits --> Windows DDK 3615 -->
Helo --> DDK Documentation.
Inside there I found Contents, Windows DDK, Driver Development Tools, The Build
Utility, Build Utility Reference, Built Utility Files, sources File.
Maybe I want to begin with UMAPPL_NOLIB and move on to DYNLINK. If Win makes
an .exe hard to build because I need to read/write physical addresses, then
I'll vote to go thru the pain of building a .dll once, post it on the web, and
then just reuse it thereafter.
Pat LaVarre
Maxim S. Shatskih
DefineDosDevice to give \Device\PhysicalMemory some DOS-accessible
name.
then OpenFileMapping on this name
then MapViewOfFile.
> Personally I'm stunningly vague on Win jargon. In Unix jargon I'd
say those
> are "user apps". I'm thinking in Win Jargon I say those are "_user
mode_
The synonims.
Max
Maxim S. Shatskih
no analogous
> to Linux "/dev/mem"?
It exists. \Device\PhysicalMemory section object.
>I have to learn to write a driver, and how to share
> memory between that driver and my user app?
Try using MmMapLockedPages( ...UserMode...) in your driver.
Max
Pat LaVarre
Looks like the sysinternals folk broke that link. Maybe the correct
substitute is:
http://www.sysinternals.com/ntw2k/info/tips.shtml#KMem
> From: Pavel A. (pav...@my-deja.com)
> Subject: Re: Physical memory access wanted
> Date: 2000/02/29
>
> PHYSMEM doesn't (quite) seem to work on win2k.2195.
>
> It opens the mapping and reads with no error
> messages - but dumps garbage.
> At 0x1000 - nothing like the sample output at the
> URL above.
Ouch, I now have reason to believe the PhysMem technique NEVER DID
WORK with the memory-mapped i/o of even a one-off custom-built PCI
card.
More specifically, in Win XP SP1 physmem chokes totally ... but maybe
the sysinternals PhysMem did mostly work back in:
Microsoft Windows 2000
5.00.2195
Service Pack 1
In that Win 2K SP1 I see the physmem.exe from sysinternals, built by
msvc, or built by MinGW gcc agree over what hex appears at offset
x1000. Curiously, asking for length x90 displays x100 bytes. And the
gcc build prints different chars for the same hex.
The ips.shtml#KMem hex of x90 bytes at address x1000 mostly agrees
with what I see, but at x103C I see xC8 where ips.shtml#KMem sees x80.
Hope this helps, thanks in advance, Pat LaVarre
Pat LaVarre
> Date: 2003-04-03 17:39:27 PST ...
>
> The PhysMem sample fails here: ...
> PAGE_READONLY );
>
> The status code is 0xc0000018, which means
> STATUS_CONFLICTING_ADDRESSES. I believe this
> return code is the result of Microsoft tightening
> up some interfaces. (Do a search on
> STATUS_CONFLICTING_ADDRESSES. You'll get, for
My inc/wxp/winnt.h and my inc/ddk/wxp/ntddk.h agree:
#define PAGE_READONLY 0x02
#define PAGE_NOCACHE 0x200
I don't see how specifying PAGE_READONLY involves PAGE_NOCACHE.
Help?!?
Cluelessly, thankfully yours, Pat LaVarre
Pat LaVarre
> From: Slava M. Usov (stripit...@gmx.net)
> Date: 2003-04-09 07:17:55 PST ...
>
> ... might achieve the same if you could use
> \Device\PhysicalMemory to gain _write_ access to
> the page directory and replace some PTE
> appropriately. This is about what a debugger does.
Anyone out there able to move this approach forward?
> ...
It also occurs to me I could do the two-machine thing of using
FireWire to peek into one host from another.
Pat LaVarre
Pat LaVarre
> Date: 2003-04-09 07:15:53 PST ...
> Just wondering, why don't you try ...
> kd and WinDbg: commands !eb, !ed, !d*, Memory window.
Thanks for sharing those links.
I wonder if you mean to say I can execute those commands from my own
user app coded in C.
I think you don't mean to say this, but I'm not sure.
Pat LaVarre
Alexander Grigoriev
your app and receive the result, through a serial port. This is how WinDbg
gets the memory contents: it issues KD commands and parses the response.
"Pat LaVarre" <ppa...@aol.com> wrote in message
news:2695edf1.03040...@posting.google.com...
Pat LaVarre
> Date: 2003-04-09 14:49:32 PST
...
> If you don't mind using two computers,
> you *can* execute those commands from your app
> and receive the result, through a serial port.
> This is how WinDbg gets the memory contents:
> it issues KD commands and parses the response.
Fun idea, thanks. I could go there for now, Win serial software is
easy enough I've done some already.
http://groups.google.com/groups?q=serial+usb+debug+group:comp.os.ms-windows.programmer.nt.kernel-mode
maybe has no relevant comment.
http://groups.google.com/groups?q=serial+usb+debug+group:microsoft.public.development.device.drivers
tells me people connect host to serial via Pcmcia/Usb, but fail to
connect serial to target and instead substitute FireWire.
Pat LaVarre