error [35] on Windows Server 2003

[Frandalf]

I'm getting a error[35] general protection fault when I try to run my Clipper build application on a PC with Windows Server 2003. No problems on Windows XP, 98 or 95.
The app is rather large, smaller Clipper apps work fine.
I use Clipper 5.3 with its Exospace linker.

Any ideas?

Thanks

 

[GriffMG]

You should probably check the "SET CLIPPER" settings in the the machines environment for DOS programs - you're looking for an E000

Search on here for E0 and should will probably find most of the other details

Good luck

Regards

Griff
Keep [Smile]ing

 

[GriffMG]

This thread will help

thread288-388992

Regards

Griff
Keep [Smile]ing

 

[Frandalf]

Thanks GriffMG, but that doesn's seem to be the problem.

I tried SET CLIPPER=E000 from the command line and putting it
in AUTOEXEC.NT.

The problem remains...

 

[GriffMG]

It does *sound* like a memory error... are there any CLIPPER settings burnt into the compiled .exe?

I'm not familiar with your linker.

Martin

Regards

Griff
Keep [Smile]ing

 

[Frandalf]

Martin

No CLIPPER settings burnt into the compiled .exe.
(as far as I recall from the head, the exospace linker can't burn in CLIPPER settings and if so...I didn't use it).

If you say 'memory error', do you mean hardware?
It's a fully new machine, high quality and delivered as a serious professional server. If anything, I don't suspect it to have bad RAM's.

It's weird. Everything worked for years and this new state-of-the-art machine refuses to run the app.


Frank

Regards

 

[GriffMG]

Hi Frank,

By 'memory error' I mean a conflict on the machine between Clipper and the systems expanded/extended memory settings (I can't ever remember the difference) rather than a hardware fault of any kind.

One of the main problems with Clipper is badly written memory management for the expanded/extended stuff - it causes problems when its not turned off.

I think Windows Server 2003 is basically NT/2K and it has different defaults for the DOS sessions from Win 96/98 - and they are different again for XP!

I think you can burn the settings in with exospace by including a command like this in the link script:

    EXOSPACE EXECUTABLE CLIPPER F225;E0;

Regards

Griff
Keep [Smile]ing

 

[Frandalf]

Well Griff,

I tried to burn the settings in with

EXOSPACE EXECUTABLE CLIPPER F251;E0

no luck so far...

Regards

 

[GriffMG]

Hi Frank,

Again, I don't know Exospace but can you post your link script details?

Martin

Regards

Griff
Keep [Smile]ing

 

[Frandalf]

OK, here are my link script details.
I use one main LNK file wich calls another.

Here is the main link file FUTIL.LNK

-------------------------------------------------------
#
# FUTIL.LNK
#


OUTPUT \futil\futil.exe

fi futil


BEGINAREA

fi main

ENDAREA

#
#
# Here I call a second link file FULIB.LNK
#
@FULIB.LNK
-------------------------------------------------------

And this is FULIB.LNK wich is called in the last line
of FUTIL.LNK

-------------------------------------------------------
#
# FULIB.LNK
#


ALLOCATE DBFCDX
ALLOCATE _DBFCDX



#
# My own and 3rd party libraries in an overlay area
#
BEGINAREA

# My own libraries...

ALLOCATE mylib
ALLOCATE fulib

# 3rd party libraries here

# The Class library
ALLOCATE CLASSY

# The FAXUAL library (CAS complient FAX functions)
ALLOCATE FAXUAL

ENDAREA
-------------------------------------------------------


Nothing much to it, I think.


Regards

 

[GriffMG]

What little I know of ExoSpace I've picked up from google!

My guess is that by default it's allocating memory from extended/expanded (as I said).

Without more exp. of ExoSpace I'm not sure where to send you for more help!

If you put the EXOSPACE EXECUTABLE command in the .LNK file then I don't have any more ideas! Did you put the last semicolon on the command?

Regards

Griff
Keep [Smile]ing

 

[Frandalf]

Yes, I did.
I added:

EXOSPACE EXECUTABLE CLIPPER F251;E0;

exactly like that.
It didn't help...

I guess switching to Blinker 7.x could solve the problem.
Do you agree?
Only, getting Blinker here (in Belgium-Europe by the way)
would force me to order it over the internet and I have no
experience with that, but that's another story.

Even better might be XHARBOUR but that would be a BIG change
for me because my application (and my libraries) consist of
HUNDREDS of PRG files and I think converting would be a nightmare!


Anyway, GriffMG, Martin, thank You Very Much for your replies.


Regards


Frank

 

[GriffMG]

Sorry Frank,

It's Monday though, so perhaps another Clipperite can offer some help this morning - if in doubt, repost your question and see if any other helpful person can offer advice!



Regards

Griff
Keep [Smile]ing

 

[TonHu]

Clipper/ExoSpace:
I could guess there's a function in one of the 3rd party libs that doesn't like/know about Win2K3, but then again, being _all_ Clipper stuff that old, it can't know about WinXP either ;-)

Few questions:
- It is not a x64 version (64 bit) of Win2K3? (That won't properly (read: not at all) run 16-bit DOS apps)
- Does the machine have > 2 GB RAM? (I'm running my Clipper 5.2e/Blinker 3.3 apps happily on an XP machine with 2 GB RAM)
- Related to the previous: Is the BigMem switch used in boot.ini?

I read something about a hotfix for XP that caused similar problems on XP, but removing the hotfix didn't solve it after all, and Win2K3 wasn't mentioned there.

xHarbour:
Depending on the style of programming used, switching to xHarbour is a very good bet for the longer future.
Major 'issue' is it needs a 'FUNCTION MAIN()', but it can easily be added to the major startup of your app, converted some of my apps already (no longer commercially or free available), and I'm quite happy.

Blinker:
If you are to order by Internet, use (or borrow) a creditcard, it usually/often offers a refund on bad deliveries/orders.

HTH
TonHu

 

[Frandalf]

Hi TonHu,

- No, it's NOT x64.
- The machine has 1 GB ram. It's a 3Ghz Pentium IV
- There is NO BOOT.INI file on the system, so no BigMem switch.

The smaller Clipper apps run happily. Only 2 larger apps have the error 35.
I'm now experimenting to try out how big the apps can be exactly before the error starts appearing, but no luck so far.

I forgot to mention that the error is preceeded by an Insufficientmemory <extended> message. So something like:

---------------
DOS/16M Protected Mode Run-Time Version 6.01
Copyright (C) Tenberry Software Inc. 1987 - 1994
DOS/16M error [1] Insufficient memory <extended>

Error [35]: General protection fault in blablabla at blabla
blablabla
blablabla
---------------

I fill in the 'blabla' because I think it's no useful info unless I want to dig into machine code (I don't)

So that's the complete message an screen.



Thanks

 

[TonHu]

You could open a special DOS-box shortcut that has a larger Extended memory setting, like 16 MB instead of Automatic, but you should refer it to COMMAND.COM, not CMD.EXE.
From that shortcut, or setting this on the shortcut to the batchfile or .exe of your app, you can try again.

HTH
TonHu

 

[Frandalf]

Hi TonHu,

Your Idea sounded good, but still no luck.

I tried all XMS memory settings in a COMMAND.COM box but
it still doesn't work.

 

[TonHu]

This is from the Clipper 5.3 Norton Guide on Protected mode DOS/16M error-messages:
<snip>
1: "Insufficient memory (extended)"

Explanation: There is not enough extended memory to load your program.

Action: check the memory to make sure that memory above 1MB is configured as extended (not expanded) memory, or use a VCPI host (such as QEMM or EMM386).
</snip (reformated for readability)>
But that's not very usefull in current past-DOS time, as QEMM and EMM386 are the extendend/expanded memorymanagers for DOS, currently the memory is managed by Windows, and that IS a VCPI host.

You could make sure that the exPAnded memory is disabled, or at least set to 0, and force it to not be used by Clipper by setting SET CLIPPER=E0;F242 (that's E-zero) in the DOS-box before starting the App, and force the exTEnded memory to at least 16 MB, as that's the maximum usable by the 286 protected mode manager of ExoSpace.

Also make sure (just a 'side'note/wild guess) that the exe is not damaged during transfer to the machine under test....... if using a floppydisk for that, it's a very reasonable cause of trouble, or running some virusscanner(s), or even being plagued by a virus or trojan can also cause this kind of strange non-working software. I'm also assuming the hardware is working as expected, because Windows would have given a subtile notify with a BSOD (blue screen of death) if any memory-chip had failed ;-)

HTH
TonHu

 

[Frandalf]

I tried all the settings in a DOS COMMAND.COM box.
I used SET CLIPPER=E0;F2242;
And I made sure I set the extended memory to the highest available in the DOS box (16384).

The EXE file is not damaged as it the same file is used from the other stations in the network (if it is newer than the one they already have, they copy it to a local directory before starting it).

So, if all that didn't help, should I suspect a hardware failure in the servers RAM?

 

[GriffMG]

Very unlikely to be a hardware failure, is it possible to send you app & data - I have a 2003 server I could try it on.

If you are able to send the app etc, email me at griff(at)finedata.com


Regards

Griff
Keep [Smile]ing