Application exemption handling error for Print Workshop 2005 - exception

A coworker of mine uses Print Workshop 2005 to make signs and job applications. Well recently when she tried to open the program it keeps giving the error:
"Application has generated an exception that could not be handled. Click OK to terminate or cancel to debug the application". Then upon hitting cancel to debug it throws another error saying a specific debugger isn't installed.
I've tried changing the .NET permissions because I read that may be an issue but so far that hasn't worked, and I would normally just try to reinstall the program but the installation disk was lost a few years ago. Also nothing has been downloaded on the computer since the last time she successfully used the application 2 weeks ago. Windows 10 is also the operating system that that specific computer uses if that helps.

Related

Access Front end works fine for most users but one user keeps having a variety of problems

I have a handful of MS Access 2010 databases that are used to keep track of various things for my group. Each Database has a dedicated back end and each user has a local copy of the front end (*.accdr) and 2010 access runtime. Only three of us have full versions of Access. Each DB has up to 6 users and some users have multiple DB's they use regularly. One user in particular has multiple problems with these DB's. One of them has a form where you put criteria in some text boxes, click a button and another form opens displaying data. Everyone else has this perform seamlessly. On hers, it throws up a dialog box asking for the criteria a second time. This is pretty universal across the DB's that she uses. On another DB, Clicking a button triggers a macro to export of a query to a MS Excel spreadsheet. This will generate an unspecified runtime error and then shutdown the entire frontend. Again, this works fine for other users.
I have systematically gone through and tried each DB from each user's computer. I have checked and rechecked the source *.accdb files I generate the front ends from. The problem seems to exist only on this user's computer.
She does have a full copy of Access 2010, but she doesn't ever use it. She also has 2010 runtime. All of our machines are connected by Ethernet to the server where the Back ends are stored.
I would expect the front end to behave the same way on her machine without unexpected pop ups or runtime errors since it behaves as it should on every other user's machine. I don't know what to look for now, and I am not inclined to throw up my hands and blame a bad setup on her machine. Is there some logical steps I can take now, since IT support is one place no sane person in my office wants to do (bad for the blood pressure). Any help, advice, or even Mystical Incantations would be appreciated.
This is a common occurrence.
The HUGE MASSIVE tip-off is that the accDB works, but the accDE (pre-compiled) does not.
And the next HUGE MASSIVE tip-off is compiling the accDB to an accDE on that particular machine ALSO works.
The reason and problem for this is that the version of Access running on that machine does not match the save version that you are running on other machines. (Specific the machine used to compile the accDB into the accDE).
While of course you are running access 2010 on all machines, the problem is the SP update version (Service Pack(s) installed).
Keep in mind that the runtime is NOT updated by windows update.
Keep in mind that running the office SP update will NOT update the runtime (but this will only apply to runtime only machines).
So, on your dev computer? Well automatic updates can roll out a SP update to office 2010.
However, automatic windows updates NEVER update the access 2010 runtime. You must install the 2010 runtime SP updates manually. So with a mix of runtime and full editions?
Well, the machines with full edition will wind up with SP updates occurring (they over write the runtime on those machines). In fact, you can’t install both full and runtime on the same machine. The installer allows this, but it is a “fake” install, and installing the 2010 runtime on machines with full edition in fact does NOTHING!! (Well, it does create a “fake” entry in the list of programs installed – but it DOES NOT actually install the runtime, since it would overwrite the full edition that already exists on the machine).
On computers with the full edition, then installing the SP updates to office, or even allowing windows update to do this will NOW cause the 2010 version to be DIFFERENT then your developer machine.
The reason why the accDB works is because Access (even the runtime) will detect that the “sp version” is different, and re-compile the VBA on the fly. Even the stand alone runtime version is able to re-compile the source VBA code.
However, with an accDE?
The code is pre-compiled, and thus no on-the fly re-compile can occur. There is no source code. The accDE should and often MUST be run + consumed by the SAME sp update version.
To reduce, or all but eliminate this issue?
Well, on your dev machine, make sure the sp2, or sp3 update to office has been applied.
On the target computers? If they are runtime only, then you MUST install the sp2 or sp3 update to the access runtime. I cannot stress that you MUST download and install the SP2 or SP3 update for the access runtime. The office sp update WILL NOT work nor will it update the runtime version on runtime only machines.
Because of the above?
I recommend you download the 2010 runtime. Download the sp3 2010 runtime update, and “slip stream” the sp3 update INTO the 2010 runtime installer.
You can then provide the customer site (or your site) with a folder on the server with the runtime to install, and WHEN you install the runtime, then the sp3 update will be included in that install.
If you (or your IT department) does NOT know how to slipstream in the sp3 update, then simply ALWAYS have then install the 2010 runtime, and then ALWAYS install the sp3 update for the 2010 runtime.
Doing the above will eliminate the issue of the AccDE having been created and compiled with a different release version of access.
Last but not least?
No question you want to continue using a compiled accDE, since with the runtime, then any un-handled error with an accDB will not only spit out an error message, but shutdown the whole application.
So:
With accDE:
Errors NEVER re-set global or local variables.\
Errors will NEVER cause a shutdown of the runtime.
Even un-handled errors will NOT cause a shutdown of your application.
Un-handled errors will NEVER re-set local, or global variables they will ALWAYS no matter what retain their values for the duration of the appcation session.
With accDB and runtime:
Any un-handled error will blow out all local and global variables.
Any un-handled error will then shut down the runtime after display such errors.
Bottom line:
Using an accDE is thus vastly far more reliability then an accDB when using the runtime.
OK, First of all, thanks for all your suggestions in the comments. We figured a method to keep my user working, so I will put it here.
We reasoned that since the executable ran fine on multiple machines, there may have been some sort of unknow quirk in my users machine that was causing the issues. I started my re-making the front end in the normal way and pushing it out to just the one user. It failed just like before.
Since she had a full copy of Access 2010, we opened the source *.accdb file directly on her machine. That time, It worked just fine.
From there I went, possibly a little overboard. But it worked out.
I opened all the forms in design view. Double check for errors, then save each form in turn. After that, I did the same with the macros. Not making changes, but checking the work.
Next I ran a compact and repair, from the affected machine.
Then I used the affected machine to create a new front end executable.
Lo and Behold, it worked. The affected user now has a completely functional front end.
This is going to make updating the front end a pain in the keister moving forward, but at least now I know what will actually work.
Thank you for your help

Task scheduler console application shows just in time debugger on exception preventing program to run again

I have a console application that runs every 5 minutes with a Windows Server Task Schedule. The program doesnt run again if the program is still running after 5 minutes, so only one instance at a time.
However, when an exception occurs, the just in time debugger appears and doesnt go away, preventing the application from running again.
Is there a way to prevent this? I want the JIT debugger to not appear so the application is finished and it will run again on the next try.
One question would be why the program is ending with an exception? Wouldn't it be better to have some redirection into file if you don't need the exception(s).
I would personally disable JIT debugger at registry. From the visual studio docs, when VS is not installed at the computer, which is probably the case.
Disable Just-In-Time debugging from the Windows registry
Just-In-Time debugging may still be enabled even if Visual Studio is no longer installed on your computer. If Visual Studio is no longer installed, you can disable Just-In-Time debugging by editing the Windows registry.
To disable Just-In-Time debugging by editing the registry:
From the Windows Start menu, run the Registry Editor (regedit.exe).
In the Registry Editor window, locate and delete the following registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
If your computer is running a 64-bit operating system, also delete the following registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
Make sure not to delete or change any other registry keys.

Launching TaskHost.exe failed, trying to run Windows Phone 8 app?

My VS 2013 setup has been humming along fine for months now. Today I tried to update to Visual Studio 2013 Update 2 RC. Just like last time when I updated to Update 1, setup failed badly with a huge list of packages marked with the "Incorrect Hash Value" error. Unfortunately MS does not have an ISO yet for Update 2 so I can't take that route to complete the update like I did last time. Now I can't run apps on the Windows Phone emulator or on the phone (device) anymore.
I believe that the failed update caused my current deployment problems since the problem surfaced right afterwards. It could be due to some other NuGet package or Extension, but the update is the most likely cause due to the timing of events.
I did extensive reading on SO and tried all the noted solutions. None of them worked:
cleaned and rebuilt the test Windows Phone 8 project (multiple times)
restarted VS2013
rebooted
Exited VS 2013 and restarted it with the Emulator left open (for the Emulator test)
repaired the Windows Phone Emulator install
repaired the VS2013 install
Nothing works. After the IDE installs the app on to the emulator, I still an error dialog box saying:
"The application could not be launched for debugging. Ensure that the target device screen is unlocked and that the application is installed."
And in the VS2013 IDE status line I see the message: "Launching TaskHost.exe failed".
Does anyone know how to fix this? Note, I tried several WP8 projects that I know worked successfully before and none of them can deploy successfully anymore to either the Emulator or the Device.
I see this was asked a month ago, but I had this issue as well. If I left the Emulator running and tried launching it again, I would have TaskHost fail with a different error.
The following was what made it work for me.
Under the following:
Solution(Right-click) > Properties > Configuration Properties > Configuration
Ensure that your main project is set to 'Deploy.'
Have many reason to error.! So, If you doing with database such as SQLLite file or SQL compact file for your project WP, you should check it is used anywhere. Or choose Embed source copy in visual. That's my fail.And i fixed ok!
Did you try from the menus?
BUILD > Rebuild Solution
That worked for me just now.

Windows Phone Emulator Application Development Error

I am encountering an error on my emulator.
I've been developing an application for windows phone, it used to run okay and there was no error.
Recently, i upgraded my visual studio, now my project cannot be loaded. So I tried reinstalling my visual studio.
After reinstalling, an Application Development Error occured. I've looked for a solution but have been unable to find one.
During my search, I found out that my emulator didn't work properly. It was starting up, but after 13 seconds it reboots again and starts up again, this loop keeps going for several minutes. After that my visual studio gives me an error.
This led me to believe that the error was caused by a virtual hard disk issue, so I choose the virtual hard disk from MicrosoftSDKs/Windows Phone/Emulation/Images/Flash.VHD and it is running now.
But after I configure my settings of the emulator to change its virtual hard disk to Flash.VHD, It doesn't work at all. It keeps restarting over and over again.
I have been trying to solve this error for 4 days.

Using Xdebug with Netbeans or Komodo fails when connecting to Mysql

I am trying to get either NetBeans or Komodo IDE to remotely debug PHP. I have a remote website installed on the development machine which is a Mac running Mountain Lion. Xdebug is installed. The website on the local machine runs normally in a browser.
However, for both NetBeans and Komodo IDE, when single stepping through the code, the attempt to execute mysqli_connect fails. In NetBeans there is the following error message:
Socket Exception occured If you have any Watches, try to remove them and restart debugger. If removing Watches does not help or you
don't have any Watches, please file an issue and provide the exact
steps to reproduce your problem. Please attach the IDE log. Attaching
your project would also be very helpful.
I have seen other people reporting this error message, but no help has been provided.
In Komodo IDE, the failure occurs at the same location, but there is no error information provided at all.
The funny thing in NetBeans is that after some single stepping through the first page of the site, if I then run the code from that point, it executes without failure and the web page is displayed in the browser! This means that the problem only occurs while single stepping.
I have seen something somewhere about a bug in NetBeans. But it seems pretty blatant that NetBeans should not be able to single step through code that tries to connect to mysql. Rather I am thinking it would be some configuration issue on my system.
Komodo IDE has the same failure whether single stepping or running any other way. It just does not get past that point.
However, please keep in mind that just running the site in a browser works fine. So what is missing that prevents the Xdebug single stepping from connecting to mysql?
** Additional information **
I have found two instances of xdebug.so on my system.
-rwxr-xr-x 1 root admin 274508 Oct 6 2011 /opt/local/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
-rwxr-xr-x 1 root wheel 202672 Sep 20 20:01 /usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
Also, there is an /opt/local/var/db/php5/xdebug.ini which references the xdebug.so in the /opt/local path. The xdebug.so in the /usr/lib path is the one that I thought was in use and which corresponds to instructions as to where it should be installed.
These are apparently two different versions of xdebug.so. Could that be related to my problem?
You need to make sure that you are running one version of Xdebug - and also make sure that this is the latest version (2.2.1 at the moment). If you can still reproduce this issue, please file a bug report at http://bugs.xdebug.org with a short sample script (that contains all the code + data!) and a remote debugging log for a debugging session using that script (see http://xdebug.org/docs/all_settings#remote_log on how to make such a log).