Silverfrost Forums

Welcome to our forums

application fails to start when run from a server

14 Dec 2017 4:48 #20987

i'm reporting this here just for the sake of anyone that experiences the same issue...

Basically, when installed on the C: drive, our application runs perfectly.

When it is started via a server disc (e.g. \\server\apps) , on some PCs, at some clients, they get this error:

Salford run time library Stack overflow: re-link program with bigger stack value (stack:reserve, commit) will attempt to trace back.

i've tried putting print statements at the start of the EXE but it doesn't get that far.

The system event viewer indicates an error 0xc000005, but that seems as though it has many potential causes.

but installing on the local drive seems to fix it.

Anyone come across this before - and has a more sensible fix?

K [/img]

15 Dec 2017 2:02 #20988

Have you tried assigning a drive letter to the Program Folder (map the program folder), then running the application?

When you say 'Installed', do you mean using an installer, or just copied to the network folder? /CHECKMATE or /RELEASE on the compiles?

Which PC's can run the application? What version of Windows are they running? What version of FTN95 are you using?

I've had this problem long ago, with V7.xx of FTN95, and making the stack bigger did not help.

15 Dec 2017 2:24 #20989

There has been a long history of stack overflow with mainly get_filtered_file@ and related variations on file open. This problem was made worse when using network or 'library' links. It also affected available memory, which was less significant with /64

There are some comments at #382 in cwplus.enh for FTN95 Ver 8.10 You could try the options of selecting new or old methods to see if it is related.

15 Dec 2017 6:14 #20990

Quoted from wahorger Have you tried assigning a drive letter to the Program Folder (map the program folder), then running the application?

When you say 'Installed', do you mean using an installer, or just copied to the network folder? /CHECKMATE or /RELEASE on the compiles?

Which PC's can run the application? What version of Windows are they running? What version of FTN95 are you using?

I've had this problem long ago, with V7.xx of FTN95, and making the stack bigger did not help.

yep, tried using a mapped drive, it didn't help.

installed with Inno Setup. I didn't try just copying the files but i had to go through hoops to get teamviewer access to the PC that was having the problem, i could try again but i'm not sure their IT manager would be keen on it...

Neither of those switches on the compiles, just:

ftn95 /silent /windows /sparam 0 /zero /f2k /CFPP

but i do have the main exe under /debug (for reasons i can't remember...)

PCs running Windows 10 Enterprise. V8.1 of the compiler.

Prompted by the error code c000005, their IT guy had tried turning off their virus checker (McAfee) but it didn't help.

I was wondering if DEP was the problem but i didn't have sufficient permission to muck around at the admin level on a remote connection.

K

15 Dec 2017 6:21 #20991

Quoted from JohnCampbell There has been a long history of stack overflow with mainly get_filtered_file@ and related variations on file open. This problem was made worse when using network or 'library' links. It also affected available memory, which was less significant with /64

There are some comments at #382 in cwplus.enh for FTN95 Ver 8.10 You could try the options of selecting new or old methods to see if it is related.

I don't think that's related because the program failed to generate any output from a 'write(,)' at the start of the EXE.

K

15 Dec 2017 6:23 #20992

Thanks for the thoughts guys, i'll post in here if i have anything positive to report. For now their IT guy is just glad that there's a clear workaround.

K

16 Dec 2017 6:53 #20996

Well, it doesn't 'appear' to be DEP that's the issue - at least, if i try to mimic the problem by setting it for all applications on my home network, the application still starts up OK.

Still testing...

K

16 Dec 2017 8:53 #20998

I've got a 'clue'.

The clients IT guy sent me a 'procmon' listing and that shows some interesting lines that i don't get at home...

26:13.2	rep5.exe	CreateFile	\\abz-asp03\rep5\\rep5.exe	NAME NOT FOUND	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
26:13.2	rep5.exe	CreateFile	\\abz-asp03\rep5\\rep5.exe.exe	NAME NOT FOUND	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
26:13.2	rep5.exe	ReadFile	\\abz-asp03\rep5\salflibc.dll	SUCCESS	Offset: 1,621,504, Length: 8,192, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
26:13.2	rep5.exe	CreateFile	\\abz-asp03\rep5\\rep5.exe	NAME NOT FOUND	Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a

but at the start i get this, so it knows the correct path at first:

26:09.5	rep5.exe	Load Image	\\abz-asp03\rep5\rep5.exe	SUCCESS	Image Base: 0x400000, Image Size: 0x10000

So, is that the issue? Something is inserting an extra \ in the path to the EXE file that prevents it loading? I tried to force this by adding the extra \ to the 'start in' folder setting for the shortcut at home, but it still worked here.

Any ideas welcomed on what might be the cause!

K

17 Dec 2017 4:00 #21002

This example appears to show that you are creating a file name (full path) dynamically in the application. I've run across inconsistencies in getting folder names from various sources, like CURDIR@, on different platforms. You might need a routine that looks for and adds, if missing, a trailing backslash on a folder name. Then the convention used in the SW is to always know that another backslash before the file name (or another folder name) is not required(?).

Just a thought.

Please login to reply.