Someone in the office hit this today.
Win10, 674-bit fully updated.
This project has been running fine.
The project crashed this morning and had to be rebuilt and only now does the above error show up.
What's the most likely thing you'd check?
The DLL's in the path.
C++ runtime (msvcrtxx) or other dll dependency
May be this can help: https://support.west-wind.com/Thread4T60C0F5O.wwt
El mié., 18 abr. 2018 18:51, Ted Roche tedroche@gmail.com escribió:
Someone in the office hit this today.
Win10, 674-bit fully updated.
This project has been running fine.
The project crashed this morning and had to be rebuilt and only now does the above error show up.
What's the most likely thing you'd check?
The DLL's in the path.
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
[excessive quoting removed by server]
Thanks for the thread reference. We're clueless, but not THAT clueless.
Working app this morning, not working this afternoon, same machine.
Project had to be rebuilt from scratch, and I suspect a file was omitted.
I need to follow some basic debugging procedures here. The client's crisis over "we need this report YESTERDAY!!!" leaked into the room, and that's really not our problem, and doesn't help things any.
This is an app I haven't worked on, so I need to ask the basic questions and follow where they lead.
The DLL is in the path. The DECLARE command, run from a command window of a freshly started Fox session, runs fine. So, we've got a few things to check next: we'll run the app through the debugger and stop before the line of code and see what the environment is like.
On Wed, Apr 18, 2018 at 1:13 PM, Fernando D. Bozzo fdbozzo@gmail.com wrote:
C++ runtime (msvcrtxx) or other dll dependency
May be this can help: https://support.west-wind.com/Thread4T60C0F5O.wwt
El mié., 18 abr. 2018 18:51, Ted Roche tedroche@gmail.com escribió:
Someone in the office hit this today.
Win10, 674-bit fully updated.
This project has been running fine.
The project crashed this morning and had to be rebuilt and only now does the above error show up.
What's the most likely thing you'd check?
The DLL's in the path.
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
[excessive quoting removed by server]
The C++ runtime DLL possibly blocked?
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Ted Roche Sent: Wednesday, April 18, 2018 1:22 PM To: profoxtech@leafe.com Subject: Re: "Cannot load 32-bit DDL wwipstuff.dll"
Thanks for the thread reference. We're clueless, but not THAT clueless.
Working app this morning, not working this afternoon, same machine.
Project had to be rebuilt from scratch, and I suspect a file was omitted.
I need to follow some basic debugging procedures here. The client's crisis over "we need this report YESTERDAY!!!" leaked into the room, and that's really not our problem, and doesn't help things any.
This is an app I haven't worked on, so I need to ask the basic questions and follow where they lead.
The DLL is in the path. The DECLARE command, run from a command window of a freshly started Fox session, runs fine. So, we've got a few things to check next: we'll run the app through the debugger and stop before the line of code and see what the environment is like.
On Wed, Apr 18, 2018 at 1:13 PM, Fernando D. Bozzo fdbozzo@gmail.com wrote:
C++ runtime (msvcrtxx) or other dll dependency
May be this can help: https://support.west-wind.com/Thread4T60C0F5O.wwt
El mié., 18 abr. 2018 18:51, Ted Roche tedroche@gmail.com escribió:
Someone in the office hit this today.
Win10, 674-bit fully updated.
This project has been running fine.
The project crashed this morning and had to be rebuilt and only now does the above error show up.
What's the most likely thing you'd check?
The DLL's in the path.
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
[excessive quoting removed by server]
_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4srf8p+3fqvk6B23ZBGvRA+ysdTPTqR... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious. Report [OT] Abuse: http://leafe.com/reportAbuse/CACW6n4srf8p+3fqvk6B23ZBGvRA+ysdTPTqRe=1wn6nb8J...
That specific EXE is now blocked by the local anti-virus solution. A customer had that problem a few weeks back. I never heard the results after we pointed out a second VFP app worked with the tools in question without a problem. We could not get in to the settings of the A/V to un-ban the EXE, nor could we confirm it had banned the EXE.
HTH, Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ted Roche Sent: Wednesday, April 18, 2018 1:22 PM To: profoxtech@leafe.com Subject: Re: "Cannot load 32-bit DDL wwipstuff.dll"
Thanks for the thread reference. We're clueless, but not THAT clueless.
Working app this morning, not working this afternoon, same machine.
Project had to be rebuilt from scratch, and I suspect a file was omitted.
I need to follow some basic debugging procedures here. The client's crisis over "we need this report YESTERDAY!!!" leaked into the room, and that's really not our problem, and doesn't help things any.
This is an app I haven't worked on, so I need to ask the basic questions and follow where they lead.
The DLL is in the path. The DECLARE command, run from a command window of a freshly started Fox session, runs fine. So, we've got a few things to check next: we'll run the app through the debugger and stop before the line of code and see what the environment is like.
On Wed, Apr 18, 2018 at 1:13 PM, Fernando D. Bozzo fdbozzo@gmail.com wrote:
C++ runtime (msvcrtxx) or other dll dependency
May be this can help: https://support.west-wind.com/Thread4T60C0F5O.wwt
El mié., 18 abr. 2018 18:51, Ted Roche tedroche@gmail.com escribió:
Someone in the office hit this today.
Win10, 674-bit fully updated.
This project has been running fine.
The project crashed this morning and had to be rebuilt and only now does the above error show up.
What's the most likely thing you'd check?
The DLL's in the path.
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
[excessive quoting removed by server]
On Wed, Apr 18, 2018 at 2:26 PM, Tracy Pearson tracy@powerchurch.com wrote:
That specific EXE is now blocked by the local anti-virus solution. A customer had that problem a few weeks back. I never heard the results after we pointed out a second VFP app worked with the tools in question without a problem. We could not get in to the settings of the A/V to un-ban the EXE, nor could we confirm it had banned the EXE.
Wow, it's like we're programming in a hostile environment!
Thanks, all, for your suggestions. Problem seems to have, er, subsided. Looks like a non-existent directory slipped into the path ahead of where the DLL was located, so the search algorithm gave up before finding the DLL. We moved the DLL to the same folder as the EXE and it's working now.
I remember a prior release of VFP (6 or 8) compiled EXE's would C0000005 on startup due to a bad path. That was always hard to resolve over the phone prior to remote access tools.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ted Roche Sent: Wednesday, April 18, 2018 2:33 PM To: profoxtech@leafe.com Subject: Re: "Cannot load 32-bit DDL wwipstuff.dll"
On Wed, Apr 18, 2018 at 2:26 PM, Tracy Pearson tracy@powerchurch.com wrote:
That specific EXE is now blocked by the local anti-virus solution. A customer had that problem a few weeks back. I never heard the results
after we pointed out a second VFP app worked with the tools in question without a problem. We could not get in to the settings of the A/V to un-ban the EXE, nor could we confirm it had banned the EXE.
Wow, it's like we're programming in a hostile environment!
Thanks, all, for your suggestions. Problem seems to have, er, subsided. Looks like a non-existent directory slipped into the path ahead of where the DLL was located, so the search algorithm gave up before finding the DLL. We moved the DLL to the same folder as the EXE and it's working now.
-
Fernando D. Bozzo -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Richard Kaye -
Ted Roche -
Tracy Pearson