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
sounds familiar
did you see this thread ?
http://masm32.com/board/index.php?topic=1101.0 (http://masm32.com/board/index.php?topic=1101.0)
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 (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.
can't be much help, Frank
i am running XP :P
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.
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.
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?
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.
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
Can you post a program that does this?
Quote from: sinsi on December 27, 2012, 03:03:33 PM
Can you post a program that does this?
Here it is one of them:
Not a problem in win8pro,
I'll boot up 7 and have a go.
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.
No problem in win7 either.
DEP and/or buffer underrun exploits are quite often a symptom of a malware infection.
Download malwarebytes (http://www.malwarebytes.org)
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?
Quote from: qWord on December 27, 2012, 05:39:57 PM
can you delete the EXE immediately after building or executing?
As far as I know, yes. Sometime I recompile a program soon
after I've added one line or changed something, that I remember
after a little time that I compiled and executed the prog.
Quote from: sinsi on December 27, 2012, 04:43:49 PM
No problem in win7 either.
DEP and/or buffer underrun exploits are quite often a symptom of a malware infection.
Download malwarebytes (http://www.malwarebytes.org)
Having gone so far, I'll follow your advice and let you know.
A scan with malwarebytes has found this:
Quote
File rilevati: 6
C:\masm32\topgun.exe (Trojan.Dropper.PGen) -> Spostato in quarantena ed eliminato con successo.
C:\masm32\examples\exampl03\lcd\lcd.exe (Trojan.Downloader) -> Spostato in quarantena ed eliminato con successo.
C:\masm32\Masm32_examples\exampl05\enumkeys\enum.exe (Trojan.Downloader) -> Spostato in quarantena ed eliminato con successo.
C:\masm32\Masm32_examples\exampl05\lcd\lcd.exe (Trojan.Downloader) -> Spostato in quarantena ed eliminato con successo.
C:\masm32\Masm32_examples\exampl06\treedemo\treedemo.exe (Trojan.Downloader) -> Spostato in quarantena ed eliminato con successo.
C:\Windows\Setup\scripts\faXcooL.exe (HackTool.Wpakill) -> Spostato in quarantena ed eliminato con successo.
I've quarantined the files for the time being, but it is strange
most of the infected files on Masm32 examples.
I'll check other disks as well and see what I find.
Frank
the masm32 files - you can ignore (malwarebytes has that option)
the last one seems to be a WPA work-around
not sure you want to delete that, either - lol
Same thing on disk F:
Quote
File rilevati: 5
F:\masm32\topgun.exe (Trojan.Dropper.PGen) -> Spostato in quarantena ed eliminato con successo.
F:\masm32\examples\exampl03\lcd\lcd.exe (Trojan.Downloader) -> Spostato in quarantena ed eliminato con successo.
F:\masm32\Masm32_examples\exampl05\enumkeys\enum.exe (Trojan.Downloader) -> Spostato in quarantena ed eliminato con successo.
F:\masm32\Masm32_examples\exampl05\lcd\lcd.exe (Trojan.Downloader) -> Spostato in quarantena ed eliminato con successo.
F:\masm32\Masm32_examples\exampl06\treedemo\treedemo.exe (Trojan.Downloader) -> Spostato in quarantena ed eliminato con successo.
I wonder if these are false positive, or they are really infected.
But where is the source of infection, if it is a real infection?
they are likely false positives
you can look in the AV sub-forum and find them listed several times
Well Dave, that's the IT world today:
-------------------------------------------------------------
- Windows has some nice bugs
- The Internet is stuffed with malwares
- The AV programs have their limits
- The whole is quite complex for anyone to manage
So far I've found thousands of documented cases of people
having the same problem as I do.
Many partial solutions applied to solve single cases are not
suitable for my PC configuration.
Malwarebytes that I installed today has found some false positive
but their elimination didn't solve anything.
If I use it to prevent web sites potentially dangerous, I can't use
the internet connection altogether.
A messy stuff indeed. :lol:
When Malwarebytes is "on" to check potentially dangerous web sites
it continually says: Blocked access to the IP 176.31.229.25/24 avp/svchost
port:xxxxx in output, and the port changes continuosly. At the same time the
internet connection becomes anavailable and to write this post I have to
turn off this feature of the anti-malware prog. Not a great prog after all.
I got the masm32 progs back to their place from the quarantine area.
Now I'm thinking about this IP: 176.31.229.24/25 I'm curious to see if I
find something.
What I found is that a nice web site should have changed
my DNS IPs from OpenDNS's ones [208.67.222.222/208.67.220.220]
to these [176.31.229.24/ 176.31.229.25].
Now I wrote back the old ones, and MalwareBytes doesn't complain anymore.
Ater all it was useful to point my attention to the underlying problem.
This solution is NOT going to solve the BEX problem, I'm afraid, but it
was a problem to be solved anyway.
:biggrin: