mamacash said:
i use Windows XP - IE 6
When opening a browser for a site I always go to I get a ie security warning
error.
The site partially opens and says I need to install Adobe flash installer
but before I can install I get the error: the instruction for oxof4b0068
referenced at oxof4b0068 the memory could not be written. I've tried to go
to Microsoft to debug but the debug process aborts. I have done a tune up
with Windows One care and tried Windows malicious software but everything
seems clear. The report did say that a possible malicious program was trying
to use a controlled system space.
I am not real literate with computers but can follow most directions. Any
help out there?
See if Dr Watson captured more detail for your crash.
E.g. Run... drwtsn32.exe
If you're lucky you will see it listed in the Application Errors list
where you can select the last entry and use the View button.
Otherwise capture its Log File Path (e.g. press Ctrl-c).
Then open a Notepad window and open drwtsn32.log
by doing a File Open in that directory. E.g. press Ctrl-o, Ctrl-v, Enter
then either press End and type a backslash to see drwtsn32.log
to select it or change the Files of type: to All Files in order to see its icon.
and open drwtsn32.log. Then press Ctrl-End.
So for all three cases you would now be a the bottom of your log.
In the first (lucky) case there would only be one dump to be concerned with.
In the others there may be multiple dumps in there not related to your current
crash event.
In any case do a Find (Up) for FAULT -> (This assumes an English version
of Windows. Translate the word FAULT into something appropriate
in the language involved otherwise.) E.g. press F3, type the find string,
press Alt-U and press Enter.
Next, confirm that the fault address bears some relation to the address
or offset that you are seeing reported. E.g. I recently had one where
the module was mshtml.dll the offset was 001822bc and my FAULT->
line starts with FAULT ->3dba22bc. Subtraction (in hex, by calculator
or otherwise) would suggest that the module load address was 3da20000
and in fact that is the load address for mshtml.dll as the load map listed
earlier in the dump proves. In your case I think the 0x0f4b0068 (those
are zeroes not o's BTW) will probably be an address not an offset and
the module will be Unknown. So you will probably be able to find that
0f4b0068 (without the 0x) as the last FAULT -> line address.
The net effect of all this is to have positioned you in the snapdump
to find the Stack Back Trace which you can find simply by paging ahead
from the FAULT-> line. Capture that whole section. It shows which
modules were responsible for the failing call. Often you can see clues
in that list which indicate the culprit is a third-party module and not
one of the standard Microsoft modules.
Good luck
Robert Aldwinckle
---
