f



New install dodgy network

Hello

Here it goes

We are installing a new system in a large factory, but the network drops 
out occasionally.

All Windows 7 level machines. Windows "Server"

The complaint is that the old system survived, yet our system bombs out.

We run our software from the server, and have done this successfully for 
years. We THINK the previous software was forced to install locally.

We are using ADS 12, VO 2.8SP4. And we are not getting any visible 
errors, just bombs out.

I have seen it bomb out as well, no errors seen, did not go anywhere 
near the VO error handler.

We have tried duplicating the issue here, but the application does not 
bomb out the same way, it just hangs.

We also think the old software did everything by SQL instructions 
whereas we are 95% ISAM and have connections to the database open a lot 
of the time.

Personally I think we may have to go remote desktop, but there are a 
large amount of users.



Anyway the questions are

1) Does anyone have any tips for running VO & ADS on a dodgy network for 
connection recovery?

2) Could Windows be killing off the application rather than it crashing?

Sorry if the questions are a bit basic, but running out of ideas







0
Martin
12/8/2016 1:21:48 PM
comp.clipper.visual-objects 12618 articles. 0 followers. Post Follow

12 Replies
344 Views

Similar Articles

[PageSpeed] 8

Well we found one problem

a log file is closed then reopened shared, packed and reindexed, then 
reopened shared.

Crashed when being reopened as advantage replication grabbed it 
exclusive, so we removed that from the replication list.

I will keep people informed if any more issues.

Martin



On 08/12/2016 13:21, Martin wrote:
> Hello
>
> Here it goes
>
> We are installing a new system in a large factory, but the network drops
> out occasionally.
>
> All Windows 7 level machines. Windows "Server"
>
> The complaint is that the old system survived, yet our system bombs out.
>
> We run our software from the server, and have done this successfully for
> years. We THINK the previous software was forced to install locally.
>
> We are using ADS 12, VO 2.8SP4. And we are not getting any visible
> errors, just bombs out.
>
> I have seen it bomb out as well, no errors seen, did not go anywhere
> near the VO error handler.
>
> We have tried duplicating the issue here, but the application does not
> bomb out the same way, it just hangs.
>
> We also think the old software did everything by SQL instructions
> whereas we are 95% ISAM and have connections to the database open a lot
> of the time.
>
> Personally I think we may have to go remote desktop, but there are a
> large amount of users.
>
>
>
> Anyway the questions are
>
> 1) Does anyone have any tips for running VO & ADS on a dodgy network for
> connection recovery?
>
> 2) Could Windows be killing off the application rather than it crashing?
>
> Sorry if the questions are a bit basic, but running out of ideas
>
>
>
>
>
>
>

0
Martin
12/8/2016 1:24:23 PM
Dear Martin:

On Thursday, December 8, 2016 at 6:24:23 AM UTC-7, Martin wrote:
> Well we found one problem
>=20
> a log file is closed then reopened [exclusive],
> packed and reindexed, then reopened shared.

Can this operation be performed by an application on the server, rather tha=
n at a client station?  All you'd need to work out is what event the applic=
ation would need to detect, to know to perform it.

> Crashed when being reopened as advantage
> replication grabbed it exclusive, so we removed
> that from the replication list.
>=20
> I will keep people informed if any more issues.

Have you overridden the error handler in any way?

Do you have code at each read, write, lock, unlock step, to wait and handle=
 any errors?  It helps if you have UDFs to put all that craziness in one pl=
ace.  Of course, then you'd need to indicate the "waiting state", and handl=
e "operation failed" in some graceful way upon return.

David A. Smith
0
dlzc
12/8/2016 2:18:34 PM
I have moved one application to the server as it is a standalone barcode 
receiver.

Crashed 3 times today and I have been looking in the event viewer

Faulty modules have included the executable and also VO28RUN.DLL

Gives me something to look at. Same executable runs for days on end at 
other customers

Example here


Version=1
EventType=APPCRASH
EventTime=131256721005636313
ReportType=2
Consent=1
ReportIdentifier=138d0b49-bd3e-11e6-80d1-00155dd20201
IntegratorReportIdentifier=138d0b48-bd3e-11e6-80d1-00155dd20201
WOW64=1
NsAppName=BarServ.EXE
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=BarServ.EXE
Sig[1].Name=Application Version
Sig[1].Value=3.0.5.76
Sig[2].Name=Application Timestamp
Sig[2].Value=00000000
Sig[3].Name=Fault Module Name
Sig[3].Value=VO28RUN.DLL
Sig[4].Name=Fault Module Version
Sig[4].Value=2.8.3.2838
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=50532a3c
Sig[6].Name=Exception Code
Sig[6].Value=c0000005
Sig[7].Name=Exception Offset
Sig[7].Value=00055b50
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.3.9600.2.0.0.272.7
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=2057
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=446b
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=446b2f0f68f8b5ba2be3d9f77caf547d
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=5360
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=5360721111379252ef6eabf7122e6662
UI[2]=J:\Apps\Gtrak3\Bin\BarServ.EXE
UI[3]=Class library for Visual Objects has stopped working
UI[4]=Windows can check online for a solution to the problem.
UI[5]=Check online for a solution and close the program
UI[6]=Check online for a solution later and close the program
UI[7]=Close the program

81 DLLS and RDDs

FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=Class library for Visual Objects
AppPath=J:\Apps\Gtrak3\Bin\BarServ.EXE
NsPartner=windows
NsGroup=windows8
ApplicationIdentity=23EC8B33178038A429DD3C078C2DCF6C

Appname and UI[3] are from bbrowser

On 08/12/2016 14:18, dlzc wrote:
> Dear Martin:
>
> On Thursday, December 8, 2016 at 6:24:23 AM UTC-7, Martin wrote:
>> Well we found one problem
>>
>> a log file is closed then reopened [exclusive],
>> packed and reindexed, then reopened shared.
>
> Can this operation be performed by an application on the server, rather than at a client station?  All you'd need to work out is what event the application would need to detect, to know to perform it.
>
>> Crashed when being reopened as advantage
>> replication grabbed it exclusive, so we removed
>> that from the replication list.
>>
>> I will keep people informed if any more issues.
>
> Have you overridden the error handler in any way?
>
> Do you have code at each read, write, lock, unlock step, to wait and handle any errors?  It helps if you have UDFs to put all that craziness in one place.  Of course, then you'd need to indicate the "waiting state", and handle "operation failed" in some graceful way upon return.
>
> David A. Smith
>

0
Martin
12/8/2016 3:31:34 PM
Dear Martin:

On Thursday, December 8, 2016 at 8:31:37 AM UTC-7, Martin wrote:
....
> Gives me something to look at. Same executable runs
> for days on end at other customers

I'd make sure the various device drivers are all up-to-date.  Does the problem show up primarily on one machine, or is it endemic to this one site?

I cannot even get Windoze to run on some machines (media server running Serviio) to stay running for more than 3 days (no evident memory leaks).  So I force it to restart every night.  Of course, your machine crashes multiple times daily.

David A. Smith
0
dlzc
12/8/2016 7:17:21 PM
It is on the server now, but seen a similar crash on another PC.

Seems to be in phases, I updated around 13:00 yesterday and it ran until 
now. (11:00)

Very odd

On 08/12/2016 19:17, dlzc wrote:
> Dear Martin:
>
> On Thursday, December 8, 2016 at 8:31:37 AM UTC-7, Martin wrote:
> ...
>> Gives me something to look at. Same executable runs
>> for days on end at other customers
>
> I'd make sure the various device drivers are all up-to-date.  Does the problem show up primarily on one machine, or is it endemic to this one site?
>
> I cannot even get Windoze to run on some machines (media server running Serviio) to stay running for more than 3 days (no evident memory leaks).  So I force it to restart every night.  Of course, your machine crashes multiple times daily.
>
> David A. Smith
>

0
Martin
12/9/2016 11:19:51 AM
OK we are getting a mix

Exception codes
c0000005
c0000006

Just need to work out what is happening

On 08/12/2016 19:17, dlzc wrote:
> Dear Martin:
>
> On Thursday, December 8, 2016 at 8:31:37 AM UTC-7, Martin wrote:
> ...
>> Gives me something to look at. Same executable runs
>> for days on end at other customers
>
> I'd make sure the various device drivers are all up-to-date.  Does the problem show up primarily on one machine, or is it endemic to this one site?
>
> I cannot even get Windoze to run on some machines (media server running Serviio) to stay running for more than 3 days (no evident memory leaks).  So I force it to restart every night.  Of course, your machine crashes multiple times daily.
>
> David A. Smith
>

0
Martin
12/9/2016 12:04:51 PM
Dear Martin:

On Friday, December 9, 2016 at 5:04:53 AM UTC-7, Martin wrote:
> OK we are getting a mix
> 
> Exception codes
> c0000005
> c0000006
> 
> Just need to work out what is happening

OK, so what if the bar code interface EXE/OBJ, is either stomping on your memory, returning after trashing the stack, or otherwise returning with unexpected / ignored overhead... that is consuming resources?

What is different between this implementation and others, besides the specific hardware?

Can you encapsulate the changes in a separate executable, or DLL, and let that piece smoke?

David A. Smith
0
dlzc
12/9/2016 1:53:16 PM
Hmm from what I have read it seems that it MAY be SMB related, or 
network, or just multiple exes using one set of DLLs.

There are a few .exes doing this but the only things they have in common 
is same directory and in VO

I have managed to produce a C0000005 in the office by shutting down an 
application, but I do need more playing with.

Same executables have multiple month uptimes elsewhere. But then I 
installed those and put them in their own C: directory


On 09/12/2016 13:53, dlzc wrote:
> Dear Martin:
>
> On Friday, December 9, 2016 at 5:04:53 AM UTC-7, Martin wrote:
>> OK we are getting a mix
>>
>> Exception codes
>> c0000005
>> c0000006
>>
>> Just need to work out what is happening
>
> OK, so what if the bar code interface EXE/OBJ, is either stomping on your memory, returning after trashing the stack, or otherwise returning with unexpected / ignored overhead... that is consuming resources?
>
> What is different between this implementation and others, besides the specific hardware?
>
> Can you encapsulate the changes in a separate executable, or DLL, and let that piece smoke?
>
> David A. Smith
>

0
Martin
12/9/2016 4:20:40 PM
Dear Martin:

On Friday, December 9, 2016 at 9:20:41 AM UTC-7, Martin wrote:
> Hmm from what I have read it seems that it MAY
> be SMB related, or network, or just multiple
> exes using one set of DLLs.
>=20
> There are a few .exes doing this but the only
> things they have in common is same directory
> and in VO

OK.  Micro$haft has long warned us that "we" should not ever work in direct=
ories off the root, that we should be operating off other drives (even if t=
hey are only mapped to C: drives), or that we should be working in a User's=
 \Documents or \AppData contents.  Can't really do this last bit on a serve=
r...

> I have managed to produce a C0000005 in the
> office by shutting down an application, but I
> do need more playing with.

Try mapping a new drive letter to your working directory, within the server=
, and operate with that drive letter reference.

> Same executables have multiple month uptimes
> elsewhere. But then I installed those and put
> them in their own C: directory

I think you are getting closer, and I am fooling myself if I think I've hel=
ped you...

David A. Smith
0
dlzc
12/9/2016 5:52:44 PM
Any ideas are worth a go, and I got into work today and found the 
following at our customers.

the barcode server moved to the C Drive is still up and running fine 
after 3 days.

The upload engine written by my minion installed on the shared directory 
crashed.


very odd


On 09/12/2016 17:52, dlzc wrote:
> Dear Martin:
>
> On Friday, December 9, 2016 at 9:20:41 AM UTC-7, Martin wrote:
>> Hmm from what I have read it seems that it MAY
>> be SMB related, or network, or just multiple
>> exes using one set of DLLs.
>>
>> There are a few .exes doing this but the only
>> things they have in common is same directory
>> and in VO
>
> OK.  Micro$haft has long warned us that "we" should not ever work in directories off the root, that we should be operating off other drives (even if they are only mapped to C: drives), or that we should be working in a User's \Documents or \AppData contents.  Can't really do this last bit on a server...
>
>> I have managed to produce a C0000005 in the
>> office by shutting down an application, but I
>> do need more playing with.
>
> Try mapping a new drive letter to your working directory, within the server, and operate with that drive letter reference.
>
>> Same executables have multiple month uptimes
>> elsewhere. But then I installed those and put
>> them in their own C: directory
>
> I think you are getting closer, and I am fooling myself if I think I've helped you...
>
> David A. Smith
>

0
Martin
12/12/2016 9:04:21 AM
4 days

So I suggest installing a troublesome .exe in its own directory on the 
local C:

Will give it to the end of week before closing our ends support log.

On 09/12/2016 17:52, dlzc wrote:
> Dear Martin:
>
> On Friday, December 9, 2016 at 9:20:41 AM UTC-7, Martin wrote:
>> Hmm from what I have read it seems that it MAY
>> be SMB related, or network, or just multiple
>> exes using one set of DLLs.
>>
>> There are a few .exes doing this but the only
>> things they have in common is same directory
>> and in VO
>
> OK.  Micro$haft has long warned us that "we" should not ever work in directories off the root, that we should be operating off other drives (even if they are only mapped to C: drives), or that we should be working in a User's \Documents or \AppData contents.  Can't really do this last bit on a server...
>
>> I have managed to produce a C0000005 in the
>> office by shutting down an application, but I
>> do need more playing with.
>
> Try mapping a new drive letter to your working directory, within the server, and operate with that drive letter reference.
>
>> Same executables have multiple month uptimes
>> elsewhere. But then I installed those and put
>> them in their own C: directory
>
> I think you are getting closer, and I am fooling myself if I think I've helped you...
>
> David A. Smith
>

0
Martin
12/13/2016 11:22:26 AM
Dear Martin:

On Tuesday, December 13, 2016 at 4:22:28 AM UTC-7, Martin wrote:
> 4 days
>=20
> So I suggest installing a troublesome .exe in its
> own directory on the local C:
>=20
> Will give it to the end of week before closing our
> ends support log.

Before it is laid to rest, you might look at the troublemaker configuration=
..  What is it's working directory, when it is executed?  Does it open and c=
reate temporary files, as part of its normal function, and are these direct=
ed to the usual temporary file directories?  Can you "fix" the application =
/ module, by invoking a .PIF for it, tweaking its environment, or establish=
ing a compatibility wrapper for it?

Entirely voluntary, but you might learn a little more.

Thank you so much for speaking to posterity here.

David A. Smith
0
dlzc
12/13/2016 2:09:29 PM
Reply: