Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
C0000005
Message
From
16/12/1998 14:36:25
 
 
To
16/12/1998 14:10:06
Fabian Valencia
Calamos Asset Managment Inc.
Naperville, Illinois, United States
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Title:
Miscellaneous
Thread ID:
00168137
Message ID:
00168212
Views:
31
>>>I've been trying to fix this C0000005 fatal error for 1 week know, I never got the error at development time but when I created my distributable disks and installed the application in users machines, it showed up.
>>>
>>>After It starting showing up intermitently I was reading and trying a lot of stuff in the UT.
>>>
>>>Some of the stuff I tryed is installing VS SP1, NT SP4, and other things like ON SHUT CLEAR EVENTS.
>>>But just until today i figured what is causing my problem, If I start the runtime version with the screen off, when my main form comes up I crash getting the fatal error, so in case this is happening to somebody, try to start the application with screen = ON or _VFP5.SCREEN.VISIBLE = .T..
>>
>>The error you describe is caused by DCOM not being properly installed on the user's machine. It is most commonly seen under Win95; it can also happen under NT or Win98 under rare circumstances where DCOM gets hosed. Take a look in the FAQ here for a destailed description of this particular C0000005 error, a method to detect when it's going to occur, and how to fix by installing DCOM support using the proper sources for each O/S.
>
>Problably yes, I've been reading your threads and basically I did install Service pack for visual studio and Service Pack for NT, I also checked if there is a key With ENABLEDCOM and the value is "Y", so I don't know what is the stupid problem of this DCOM thing.

SP1 for Visual Studio has nothing to do with it. Any NT 4 system using a VFP6 application needs to have at at least NT Service Pack 3, or preferably Service pack 4, installed in order to load DCOM support.

With NT, it's easy to accidentally revert the changes made by installing the Service pack; if you have to go back to the original WInNT disk for much of anything except a printer driver, it's possible, and in some cases likely, that NT's older files will be reloaded, especially if you have to use the Repair Option of NT Install and have not updated the Emergency Repair Disk and reference files on the hard drive with the RDISK utility. There should be no harm in reapplying the latest Service Pack applied to the system unless you've also installed hotfixes from Microsoft since the installation of the Service Pack.

-EVERY- station running the application needs to have DCOM properly installed; it is not a server issue but a workstation issue. Installing SP4 on the server does nothing towards solving the DCOM issue on other stations.

If you have the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLE key and the registry value EnableDCOM is present and you still have the problem, something hosed DCOM. Creating the registry jkey and registry value by hand doesn't solve the problem; it must be created by installation of DCOM on the system for the necessary shared components to be updated. (IOW, if you just create the registry key and registry value by hand with REGEDIT, you have not fixed the problem.)

On the NT System, what does NT report as it's current release level (open My Computer and click Help/About Windows NT to display the information.) It should show that NT Build 1381 with either SP3 or SP4 has been installed. If that is not the case, you need to apply the correct Service pack.

Is IE installed on the NT box? If so, what version is installed?

>
>Thanks in advance for any helpe, this is way too much for something that should not be happening.
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Reply
Map
View

Click here to load this message in the networking platform