access violation in kernel32.dll. how to fix it?

Hans Meiser

unread,

Mar 4, 2001, 6:31:12 PM3/4/01

to

A customer reported an access violation in kernel32.dll generated by my
application. I have no idea how to fix it. any suggestions?

Michael (michka) Kaplan

unread,

Mar 4, 2001, 7:57:58 PM3/4/01

to

Um, a bit more detail is needed than this..... kernel32 has a LOT of
functionality packed into it. Like what were they going, and then you could
tell what sorts of things your code is doing?

If they have Visual C++ on a machine, you can also try building with PDBs
and give them the PDBs, sometimes it will give them a bit of a callstack and
you can see more about where the code was when it crashed.

--
MichKa

a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Hans Meiser" <ha...@meiser.com> wrote in message
news:#gMXGJQpAHA.1472@tkmsftngp04...

Hans Meiser

unread,

Mar 5, 2001, 7:23:34 AM3/5/01

to

I would be able to get the address where the access violation occured,
nothing more and nothing less. But I don't have the .map file of kernel32,
so it's useless.

Michael (michka) Kaplan schrieb in Nachricht
<#jkPT9QpAHA.1836@tkmsftngp03>...

Dragomir Stoichev

unread,

Mar 5, 2001, 8:12:19 AM3/5/01

to

Hans Meiser <ha...@meiser.com> wrote in message
news:#gMXGJQpAHA.1472@tkmsftngp04...

Ussually this mean that somewhere in your source you call a Kernel function
whit a invalid pointer. To determinate which function generates the
exception run your application in debug mode. When the exception were trown
watch the call-stack debugger window from "View\Debug Windows\Call Stack"
and find which function throw the exception. After do this carefully check
the function's parameters, especially pointers and/or handles. And then I'm
sure that you find the BUG.

Michael (michka) Kaplan

unread,

Mar 6, 2001, 1:14:55 AM3/6/01

to

Actually, you might be able to get a LOT more than that.... such as a call
stack.

And again, by pinning down what is happening when the crash occurs, you can
narrow it down further.

The question, as it stands, cannot really be answered.

--
MichKa

a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Hans Meiser" <ha...@meiser.com> wrote in message

news:uY$hf6WpAHA.2012@tkmsftngp05...

Hans Meiser

unread,

Mar 6, 2001, 4:44:12 AM3/6/01

to

this only happens on a customer's system. I am not able to debug there.

thank
s
Michael (michka) Kaplan schrieb in Nachricht ...

Hans Meiser

unread,

Mar 6, 2001, 4:43:59 AM3/6/01

to

this only happens on a customer's system. I am not able to debug there.

thanks

Dragomir Stoichev schrieb in Nachricht <#24EVWXpAHA.1444@tkmsftngp03>...

Carey Gregory

unread,

Mar 6, 2001, 2:40:36 PM3/6/01

to

"Hans Meiser" <ha...@meiser.com> wrote:

>this only happens on a customer's system. I am not able to debug there.

You seem to be looking for magic.... Sorry, all out of magic.

If you have no access to the problem machine, then your only hope is to
reproduce it on your own system. Something about the customer's system is
different, and you need to figure out what that something is. It could be
system configuration, operating system version, shared DLL's present on the
machine... all sorts of things. But since I don't know a single thing about
your app, I can't even guess where you should look first.

--
Carey Gregory

Michael (michka) Kaplan

unread,

Mar 7, 2001, 9:21:12 AM3/7/01

to

Well, you need to do work as I suggested to try to isolate the problem.

No one can read your mind.... even that would not help since you do not know
the problem. No one can read your customer's computers stack and determine
the problem for you.

They are not easy problems, but you must do the work you can to isolate:

1) find out what the customer does that causes the crash
2) look at your own code to see what APIs you call in that time
3) get info from them about environment, etc.

and keep working to get the problem solved that way.

It may prove cheaper to go onsite, hook your laptop onto their network, and
run MSDEV remotely to debug the problem, rather than go back and forth
forever. But no matter what you do, the current plan you have chosen (ask
here with no information and expect an answer) will clearly not get you
anywhere.

--
MichKa

a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Hans Meiser" <ha...@meiser.com> wrote in message

news:uXcSGGipAHA.1072@tkmsftngp03...

Gary G. Little

unread,

Mar 7, 2001, 11:52:39 AM3/7/01

to

Did you not generate a map file of your application when you built it? If
not, I would suggest that you do that. That call stack that has been
suggested to you, several times, can then be used to trace back into your
code to find your offending statement. The bug may pop it's ugly head up in
Kernel32, but I'll bet you a donut it's because of a faulty pointer or
variable you passed a Kernel32 function, either directly or indirectly.

And of course you can debug at the customers site. One way is to pack your
bags and GO THERE!!. The other is to set up for remote debug via a modem and
the serial debug side of the Visual Studio IDE. Another is to liberally
sprinkle diagnostic messages throughout your code. There are a multitude of
things you can be doing to debunk this problem yourself, instead of whining
on the net about how you can't. My Granma Barclay always told me "Can't
never could do nothen."

I'm sorry, but you seem to be unwilling to help yourself.

"Hans Meiser" <ha...@meiser.com> wrote in message

news:e6wd#FipAHA.1352@tkmsftngp03...

Eric Wu

unread,

Mar 18, 2001, 2:20:58 AM3/18/01

to

Hi,
Do you check the Drwtsn32.log? maybe you can get the call stack
information from there!

Eric