I am trying to load a security Windows dll that does not run under a debugger. When I load the dll I get a SIGTRAP, and then wine breaks in its debugger.
My understanding is that if I run wine as opposed to winedbg I am not running under a debugger. But, if there is a crash or some other exception wine will start a debugger.
I sent some memory dumps to the developer of the security dll, and he said that it behaves like it was running under a debugger. He's question was something like does wine have an always "on" debugger?
I would appreciate any help.
Thanks,
Dan Timis Muse Research, Inc.
Dan Timis wrote:
I have seen this kind of thing before. I had a program that was doing this, and to get around it I changed the "Windows version" for Wine from one of the "DOS-based" ones to one of the "NT-based" ones.
This may or may not work for you. It depends on what exactly the program is trying to do to detect a debugger. I just tried setting the version to NT because I figured that the things it allowed were closer to what would be allowed on Linux, and it happened to be that whatever it tried to do on NT gave the "correct" answer on Wine.
But yes, the Wine debugger loads as a new process only after a crash is detected. What is happening is the program is poking around in memory somewhere and seeing something different from what it expects.
Cheers, -ajp
since we get a SIGTRAP more likely an int 3 instruction under windows (9x), if the program is run under a debugger, the debugger will get the interruption. some protection mechanism set their own exception handlers (allowed under 9x) to detect whether a debugger is present (the handler is called only if no debugger is present) so setting the windows version in wine to NT will let the program (if correctly designed) to use some other mechanism and you may succeed in running your program
A+
-
Alex Pasadyn -
Dan Timis -
Eric Pouech