I upgraded a VC++ 6 project and only one of the dialog's work. All the others end up getting an assertion error in occcont.cpp line 925 - ASSERT(IsWindow(pTemp->m_hWnd));
This doesn't happen for all the controls it's trying to create for this dialog only 3 out of 56.
I can't figure out what could be causing it. I'm running on Win 7 64 bit but the app is built for 32 bit.
I tried running the .exe in XP SP2 compatibility mode but that didn't work.
Could there be a setting I need to change for this?
Also, can I view a form designer? I can't seem to locate any sort of option for it. I thought if I could bring up the designer it might provide some better insight.
It looks like you are using some sort of an AciveX controls and creation fails. Make sure that control is properly registered.
Another possibility is that control is still somehow dependent on the old MFC library that is not present in your system.
Related
This may be trip down memory lane. I have been asked to fix some code that was written 8 years ago. That in itself is OK. I have a Win 7 64 bit PC. As I now use VS2012 I had to install 2005 luckily had a copy still. Then all the updates from MS so that it will work with Win 7 64 bit. Create a dummy MFC app to make sure it all works. So far so good. Next I get the SDK to target the code to it is running on a Moxa UC7124 ARM4i. I get UC712XCE_SDK_V2.0.msi and install it.
Now the problem starts. I cannot see the Moxa platform inside VS2005. If I load the solution it comes up with the platform but skips compile. My guess is that VS cannot find the SDK. I have tried many things but obviously not the correct thing yet, I checked for environment variables and find none, registry has no entries.
I look inside Tools | Options under Projects and Solutions VC++ directories but cannot find the platform I only get Win32. So for the first time in a while at the moment I am lost. Has anyone got any ideas why I cannot get the Moxa SDK visible inside VS2005?
After several days progress has been made ....... but not yet fully working. My view was that there must be some permissions issue in Win 7 when trying to load older SDK's, so I uninstalled the SDK first. Next I right click on the SDK's msi and in security tick "run as compatibility" and choose "Previous version of Windows". I can now target my solution correctly. So this part appears to be working now and next I have to fix all the compile/linking issues. Still got a big hill to climb but fingers crossed when I get to deploy this that it is all going to work OK.
I have been searching for the answer for this for 2 days. We have an application that uses ReportViewer 9. However, clicking on the print button in IE10 causes the browser to stop working (with the "Debug" or "Close Program" buttons). Everything else seems to work fine.
We tried using ReportViewer 10 but we get the same issue.
We are using Visual Studio 2010, Windows 7, IE 10, and targeting .NET 4.0. The crashes happen in the IDE and through IIS.
EDIT: Things I Have Tried:
I have tried adding my website to Trusted Sites, lowered the security setting, and I think I've tried every possible combination of checkboxes in the "custom" security box.
I've tried enabling Protected Mode and Enhanced Protected Mode, with a variety of check box combinations from Custom security level that sounded promising.
I've tried forcing IE10 to run in 64-bit mode (including the tabs), but our app forces the tab to run in 32-bit anyway.
Someone suggested that it might be a Kill Bit issue, so I tried editing the registry to ignore kill bits just to see if it would work (it didn't).
Also, I'm pretty sure I've tried just about every permutation of all the variables I've already mentioned. (I'm a little burnt out at this point, so I might have missed 1 :S)
This thread seemed promising but I could not get it to work. It is talking about Win8 but I thought I might be able to apply them to my situation.
I found a suggestion changing the BuildProvider assembly to type="Microsoft.Reporting.RdlBuildProvider, Microsoft.ReportViewer.WEBFORMS ..." (instead of Common), but so far that is not working either.
Tried installing Report Viewer 11, and installing a very old version of our application. Both give me the same result.
Aha! OK, so it turns out that my issue is NOT with ReportViewer, but rather with RSClientPrint. Once I did a google search for that I quickly found that the answer is: Upgrade to Sql Server 2008 R2 SERVICE PACK 2.
The version of RsClientPrint you get with R2/SP2 is 10.50.4000, while the version I had was 10.50.1600.
In conclusion, it appears that RSClientPrint 10.50.1600 is NOT COMPATIBLE with IE10, but version 10.50.4000 IS.
I REALLY hope this helps someone else!!
I am using "Microsoft Visual Studio" to work with an "MFC application".
I am using "Installshield" to create the setup file for this application.
I get a "setup.exe" file.
If I run this setup on a "Windows XP 32 bit" machine, the installation ends properly.
Yet, when I try to start the installed program, I get the message:
"The procedure entry point _except_handler4_common could not be located in the dynamic link library msvcrt.dll."
In debug mode, I can't find the moment the error occurs because whatever the breakpoint I put in the code, the message appears before reaching the breakpoint, I guess at the very beginning of the program execution...
Note: It works for Vista 32 bit and Seven 64 bit.
It appears lots of people do have the same problem but I couldn't find a solution for myself.
Can you help?
Thank you.
Welcome to the world of DLL hell and application dependency analysis.
I found that DLL on my Win8 machine in the SYSWOW64 (32bit System32 folder ) with version 7.0.9200.16384. Looking at it using Dependency Walker I can see it in fact exports the function you are looking for.
I also see on my InstallShield machine a merge module called MSVCRT.MSM that redistributes version 6.00.8797.0 of this file. However when I look it using Dependency Walker, I see it has the exported functions _except_handler2 and _except_handler_3 but not _except_handler_4_common.
So therefore you need a newer DLL and that merge module won't help you. Microsoft used to have this cool website called DLL Help Database that told you all the versions of a file and what shipped them but sadly they killed it.
BTW, I can also see that this DLL is installed with Windows these days. Windows XP? I'm not so sure as I'd have to fire up a VM and look.
A couple possible resolutions:
Find out what SP or Hotfix of Windows fixes this and make it a dependency of your MSI.
Grab the DLL from a Win 8 machine and add it to your INSTALLDIR and deploy it privately.
One final note. This is either caused by the version of Windows XP comes with an old version of the DLL ( A related KB Article says it does ) or that a third party application whacked the DLL causing the problem. Some more study is required here.
I recommend you first try installing the MSVC Redist version 2008. That one does include the implementation of the missing function.
This post is old but I wanted to leave my solution since this problem was hell to me. My python app was working for Linux, Win7, 8 and 10 but WinXP refused to work with that message.
I was using py2exe to get an executable and it will put some DLLs along with the exe file.
Deleting some dlls from the exe's directory was the only thing that make the app work in XP and continue working in the other systems:
[ "POWRPROF.dll","IPHLPAPI.DLL","USP10.DLL", "DNSAPI.DLL" ]
Also distributing "Microsoft.VC90.CRT" directory along with the exe file, with it's manifest and DLL files.
I hope this will be useful for someone, since it took me weeks to figure it out.
(i know the OP wasn't working with python, but the error is just the same)
Your program has a dependency which is not being satisfied on Windows XP. You might try using Dependency Walker to identify it, or you might check for known limitations. For example, Visual Studio 2012 doesn't support Windows XP until update 1 and a build option change - is that what you're using?
The problem was probably because you might used a corrupted DirectX version on your Win XP. It happened to me as well because I randomly downloaded a DirectX setup which was corrupted and caused these. The solution I did was is I deleted all the files that has anything to do with directX from C:Windows/System32, deleted the directX from add/remove program as well and completely removed the whole registry key from regedit. Local_machine/software/microsoft/DirectX... What I did then was found a original values and keys for DirectX 9 on the net and made a new registry key.
The DirectX folder was once completely and originally back on regedit and it showed in dxdiag that the directX is installed.
In case you encounter crashes in the game, I suggest you to download .NET Framework 3.5 Service Pack 1 and then make a backup on your PC (If you're not using nVIDIA graphic cards like I do, I use ATI Radeon) and download nVIDIA PhysX system software driver and see if it works. (You need nVIDIA phydX drivers to run this game without crashes only if you use Win XP, the problem shouldnt encounter on Win 7) In case the drivers screw up your PC (The nVIDIA PhysX one) you will be able to restore your old PC function before those drivers (If you made a backup of your PC, I suggest using Acronis Boot for backups) it means you're totally out of luck if you're not able to get the nVIDIA PhysX on ur for example, ATI graphics on Windows XP, because without nvidia physx, on Win XP, Metro wont run, while on Win 7 / Vista / 8 it should.
I just installed the latest VS 2017 and was running into the same problem. I googled everything but couldn't find any solution, so I just defined it myself:
extern "C" int _except_handler4_common() {
return 0; // whatever, I don't know what this is
}
I've spent the last 8 hours picking my code apart with this exact same error and it turned out to be a line of code in my application, specifically a check for IPv6 support in the OS:
conf.IPv6Disabled = !(Socket.OSSupportsIPv6);
I commented that line out and voila, error disappeared.
This problem persists to every software or game that requires windows 7 or 8 or vista but is made run into windows xp. So if you want to resume or start your program you need to upgrade your windows to 7 or 8 or vista as per the system requirements of the program.
HOPE IT WAS HELPFUL
THANKS
I'm working on an application developed for Windows XP SP3, using VB6. I'm currently in the process of getting it to work on Windows 7, but am encountering a problem with one of our custom OCX files.
When attempting to load a form that contains an instance of the control contained in the problem OCX, the following error is produced:
Failed to load control 'x' from y.ocx. Your version of y.ocx may be outdated. Make sure you are using the version of the control that was provided with your application.
I've checked the version numbers and they're all correct and referencing the proper version. The OCX registers fine, and all the expected registry entries are present.
Inspection with DependencyWalker shows no missing dependencies.
The software works fine under XP, and this is (seemingly) the only issue when running on Windows 7.
Interestingly, if I run through the VB6 IDE using a VB6 group (with the offending OCX part of the group, and the application the startup project), I don't have the issue. Running the application on it's own through the IDE still presents the error.
Any ideas on what could be missing which would cause the application to throw this error?
Error occurs on both Windows 7 Professional and Home Professional, both 32 bit.
This is almost certainly an interface compatibility problem. COM interfaces are versioned entirely separately from your Major/Minor/Revision numbers, which are little more than comments except as used by Installer.
Somewhere along the line you broke binary compatibility, and you are trying to deploy a library with a newer interface than your application was compiled against.
These version numbers are found in keys such as:
HKEY_CLASSES_ROOT\CLSID\{class Id GUID}\VERSION
Your program needs to have its old reference to the OCX removed, a new one set, and then it must be recompiled. This also means deleting any instances of the control and adding them back one by one.
I doubt this is a Windows 7 issue.
I would suspect this is a UAC problem. Try turning UAC off to see if that solves the immediate issue. If it does then you have to regsiter everything using 'run as administrator' and/or create a manifest for you application.
Sounds like on of the controls included in your OCX is having issues loading, not a general registration error. Look at the constructors for x control, and see if they are doing anything that disagrees with UAC or such. One way you can debug this is put some kind of a break before the control is initialized, and debug the application from Visual Studio (remember to create the PDB's in VB6), and then carry on from the break to see why the control isn't initializing.
This is trouble shooting question.
Our application's development environment is VS2005 C/C++, VB6 based GUI.
we use also componentone for ActiveX control(vsflexgrid8).
application performed well in Windows XP, but in Windows 7, there is some problem in GUI.
rebuilded almost all C/C++ code and VB6 code in Windows 7
our build system is so poor and because I joined this team a month ago, building all codes are a bit hard
But this (maybe) last problem is not related to build, I think.
all other processes and GUI process are start well. but when click some menu in GUI, all user controls become invalid.
error message seems like this:
'-2147417848 (80010108)' occured
runtime error.
Automation error.
Invoked Object disconnected from
client.
above message is not identical to real message since real message is our native language(Korean).
when googling with this message, I'm able to gather some informations.
the most possible case is when using OLE Automation for Microsoft Office Objects.
But our GUI(VB6 developed) does not use Microsoft Office Objects.
And problem-causing page/control's are commonly use componentone modules.
So, if experienced similar problems, please help me.
In Virtual Machine Windows XP mode, there is no problem. But I'm strongly willing to develop in this environment.
Thank you for your help.
'Automation Error' just means that an error was raised from within the ActviveX control, but that the developpers did not add a description to it. So the cause could be anything.
A common source for this kind of errors are write errors to protected folder (The Program Files folder for instance) or forbidden Registry Read/Write actions. You could try installing the program to another location or to run it elevated.
Hope this helps at least a little.
As Dabbler says, this means there has been an error in the ActiveX component.
Does any of your C or C++ code run before this error happens?
Are you using the latest version of the ComponentOne control? Perhaps it's worth checking whether it is supported on Windows 7, and contacting their technical support?
You could debug the VB6 and C/C++ on Windows 7 to track down which bit of code triggers this problem. This is possible with Visual Studio 2005, which you say you have, or WinDbg which is free.
I solved this problem by Windows Updates.
Since about 20~30 updates are performed at once, I can't know what update solves this.
I guess Visual Studio 2005 security updates may the reason for this trouble.
Anyway, my application runs well in my Windows 7 machine.
Thanks to All.