News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Did anybody stumbled upon Win BEX exception?

Started by frktons, December 27, 2012, 09:53:49 AM

Previous topic - Next topic

frktons

I've tried to solve this problem by myself, with no lucky.
So maybe someone of you has passed through this problem
and know how to fix it.

The problem seems sort of protection that win uses against
possible virus that try to mark non-executable area of memory
as executable ones, in order to execute themselves.

It happens for my smaller programs that tend to work fine
after I compile them. But the day after, or some day after,
don't work anymore. Windows tells there is this BEX problem
and won't run the executable until I recompile it.

Being it quite annoying, if someone knows how to solve this
kind of problem, I'll be glad to know.

Thanks

Frank
There are only two days a year when you can't do anything: one is called yesterday, the other is called tomorrow, so today is the right day to love, believe, do and, above all, live.

Dalai Lama

dedndave


frktons

Quote from: dedndave on December 27, 2012, 10:39:22 AM
sounds familiar
did you see this thread ?

http://masm32.com/board/index.php?topic=1101.0

Thanks Dave, the problem is different in my case.
Because the Stack handler was involved, I added a new directive
to the pgm that gives this problem, ".stack [4096]"
and now I've to wait to see if tomorrow or in two-three days
something happens.
My consideration doing this was that pheraps the authomatic
stack size could be on of the problem, even if the discussions
I've read on win forums tends to explain the exception in other
ways, that I tried and didn't work altogether.
There are only two days a year when you can't do anything: one is called yesterday, the other is called tomorrow, so today is the right day to love, believe, do and, above all, live.

Dalai Lama

dedndave

can't be much help, Frank
i am running XP   :P

frktons

Quote from: dedndave on December 27, 2012, 11:02:02 AM
can't be much help, Frank
i am running XP   :P
You are probably safe with XP, I think this kind of "protection"
was included starting with Win Vista.
Will see in few days if I solved the issue with the stack enlargement.
There are only two days a year when you can't do anything: one is called yesterday, the other is called tomorrow, so today is the right day to love, believe, do and, above all, live.

Dalai Lama

Donkey

Hi frktons,

Do you have a dump of the exception information to post ? It's much easier to trace the problem if you know the exact page where the DEP tried to execute code in an NX or XD section, also the exact error code (ie c0000005) is critical to determining the source of the problem. If this is happening through a wide range of programs you might want to look at common routines in those programs that may be buggy (my vote). The other option is that you have malware that is attaching itself to your process or executable and trying to exploit a buffer overflow in order to generate an exception and execute malicious code. This can be checked by inserting a top level exception handler to verify that any overflow was generated inside your program, yours will have to be the first handler called in the exception handling chain. I would start by running the code in OllyDbg until the exception occurs and find out what process or module caused it.  Another thing to check is to make sure your drivers are up to date, this problem was reported as an intermittent problem with Nvidia graphics card drivers, it is easily solvable with a driver update. With Vista in particular, JAVA ran into this problem when IE was being executed, you will be required to update your version of IE or turn DEP off.

All in all you have not provided enough information to diagnose the problem, perhaps posting some faulty code would help but at least a debug dump of the exception information is critical. Are you running 32 bit or 64 bit Vista ? Adjusting the size of the stack might work but it doesn't point you to the root of the problem, it simply masks it. I have built a lot of programs on Vista and have never seen this problem so everything I suggested is only general advice, without more re-creatable data it isn't possible to be specific.
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

frktons

My PC speaks Italian:
Quote
  Nome evento problema:   BEX
  Nome applicazione:   btx.exe
  Versione applicazione:   0.0.0.0
  Timestamp applicazione:   50b8c896
  Nome modulo con errori:   StackHash_0a9e
  Versione modulo con errori:   0.0.0.0
  Timestamp modulo con errori:   00000000
  Offset eccezione:   02581000
  Codice eccezione:   c0000005
  Dati eccezione:   00000008
  Versione SO:   6.1.7601.2.1.0.256.1
  ID impostazioni locali:   1040
  Informazioni aggiuntive 1:   0a9e
  Ulteriori informazioni 2:   0a9e372d3b4ad19135b953a78882e789
  Ulteriori informazioni 3:   0a9e
  Ulteriori informazioni 4:   0a9e372d3b4ad19135b953a78882e789

Is this what you mean Edgar?
My pc is Win 7/64 bits. And the problem happens as I explained
in the previous posts.
The program is quite small, and was written by Jochen, not me.
If I recompile the prog, it works without problems.
No OllyDbg has ever seen my fingers on it.  I can check the size and
timestamp of the program in order to see if some malware attaches
to it [hoping these parameters change then], other than increasing
stack size.
I use Kaspersky Internet Security 12, and so far has never failed.
But, who knows?


There are only two days a year when you can't do anything: one is called yesterday, the other is called tomorrow, so today is the right day to love, believe, do and, above all, live.

Dalai Lama

Donkey

Hi frktons,

That crash dump appears all over the internet with only slight variations, I scanned a few but found no explanations. You can try to Google for "StackHash_0a9e" there are thousands of hits, one of them has to have a solution.
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

frktons

Quote from: Donkey on December 27, 2012, 01:56:48 PM
Hi frktons,

That crash dump appears all over the internet with only slight variations, I scanned a few but found no explanations. You can try to Google for "StackHash_0a9e" there are thousands of hits, one of them has to have a solution.
Thanks for the hint Edgar. I already did a search, but a new one
couldn't hurt. :t
There are only two days a year when you can't do anything: one is called yesterday, the other is called tomorrow, so today is the right day to love, believe, do and, above all, live.

Dalai Lama

sinsi

🍺🍺🍺

frktons

There are only two days a year when you can't do anything: one is called yesterday, the other is called tomorrow, so today is the right day to love, believe, do and, above all, live.

Dalai Lama

sinsi

Not a problem in win8pro,
I'll boot up 7 and have a go.
🍺🍺🍺

frktons

Quote from: sinsi on December 27, 2012, 03:23:17 PM
Not a problem in win8pro,
I'll boot up 7 and have a go.

Another strange thing that I've noticed, after a program stops to
be executable, the folder that contains all my asm proggie is
flagged as read-only.
There are only two days a year when you can't do anything: one is called yesterday, the other is called tomorrow, so today is the right day to love, believe, do and, above all, live.

Dalai Lama

sinsi

No problem in win7 either.

DEP and/or buffer underrun exploits are quite often a symptom of a malware infection.
Download malwarebytes
🍺🍺🍺

qWord

Quote from: frktons on December 27, 2012, 03:29:35 PMAnother strange thing that I've noticed, after a program stops to
be executable, the folder that contains all my asm proggie is
flagged as read-only.
can you delete the EXE immediately after building or executing?
MREAL macros - when you need floating point arithmetic while assembling!