The error as seen in the image is a compiler error -1073741502. I have searched SO and Google with little success. Tried to debug the process and was not able to determine what the issue is causing the error. The error has been occurring for some time and is random with no apparent pattern in the data or operation. This is also in a VB website using .net 4.0. The report RDLC has been recreated 2 times to see if the issue would be resolved but was not successful.
The only way to get the application to continue past this error once it occurs is to do an app pool reset. This is something we would like to avoid doing for obvious reasons.
Any help and suggestions are appreicated.
Related
I suppose that this is more of a curiosity as opposed to an actual issue, but I thought I'd ask about it anyway. There are times when an uncaught error occurs in a server-side NetSuite script using SuiteScript 2.0/2.1 (2.x), but instead of seeing a "SYSTEM" scripting log entry, there's nothing. It gives the appearance of a script just stopping for no reason. Now, I know this can easily be avoided by wrapping everything within a try-catch block, but that's not what I'm trying to discuss here.
Does anyone have any insight into why a script would just stop without any SYSTEM error logging? It's just something I find interesting given that with the 1.0 API uncaught errors would always get logged. And it's not a guarantee that an uncaught error won't be logged as a SYSTEM log. It seems more common with map/reduce scripts, but unless memory is not serving correctly I believe that I have seen it happen with suitelets and user event scripts, too.
Just thought that I'd pose the question here to see if there was anyone who might know a little something about it.
This is actually covered in the system help for Map/Reduce scripts. They do fail silently. I've not seen this in any other script type.
I have a form with a button which opens a new form to add a new record to a table.
In Access on my PC (full version), everything works.
When I try to run it on a server with Access Runtime, I get an error saying something like:
this application has stopped working due to a runtime-error. The
application will now be closed
(I have the Dutch version, so I hope this comes close to the English dialog box message).
I debugged the VBA, but that doesn't seem to be the problem.
It has worked before:
Private Sub Knop62_Click()
DoCmd.OpenForm "Machines Toevoegen", , , , acFormAdd, _
acDialog, OpenArgs:=Me.Installaties_Id
End Sub
Well any un-handled error in the runtime will spit out the error message, and then as you experienced exit the application.
there are a good number of ways to approach this:
Improve error handling - make sure you don't encounter any un-handled error. I find this can be a LOT of work.
Another way? Compile your application down to a accDE. When you use a accDE, not only does the runtime ignore errors, not only does it NOT shut down?
It also means that all of your local and global variables are NEVER re-set. so global vars, and even global reocrdsets or anything else will retain their values, and do so even with errors. As a result:
Your application runs like a un-stoppable fright train.
Your local and even global variables retain their values. This allows use of application wide settings and variables that never re-set. And no re-sets ever occur even for un-handled errors. They remain intact for the given session (since the time the application was launched).
So, I would try running your application as a accDE on that server. It will not only become vastly more reliable, but it will also not shutdown on un-expected errors and even better it will retain the value of variables even when having encountered errors.
So it looks like you have some un-handed error. You can go on a treasure hunt to find this error, or just try a accDE in the meantime, and perhaps in the new years you might eventually track down the error or issue. But until then, just compile your application as a accDE.
To compile:
First, from VBA editor (just hit ctrl-g). And from the menu bar choose debug->compile. You MUST ensure that no compile errors exist before the next step.
If above compiles, then from UI (main ribbon), go file->Save and publish
From that panel, choose Make ACCDE.
Access will compile your application into a "access executable". Now try running this application with a accDE file extension on the other computer.
I randomly get an error saying HasFile is not a member of FileUpolad.
I'm using a file upload button to upload images to a server. This usually runs; however, every once in a while it errors out. Sometimes the error is caught by Visual Studio during run time, other times it will be a Server Error in Application. Compilation Error when I load the page in debug mode. I've check dependencies and everything seems to be fine. Even the IntelliSense brings up HasFile with I am writing the code.
Usually re-writing the line or restarting Visual Studio resolves the issue, but it keeps coming up randomly.
I happened to figure out what the problem was. Since it was my first time doing this I had a test class in the solution. The test class was named FileUpload. Rookie mistake. I can't believe I didn't catch that earlier!
I have a Word Template with VBA.
Wherever I need to I handle my errors with either a "On Error Resume Next / On Error Goto 0" round a call to a collection that might fail, say, or a full error handler (On Error Goto label: / Resume exit_label:)
Tools Options is set to Break on Unhandled Errors
I have found that for this template (only it seems) that unhandled errors are not being reported. The VBA code just stops running without telling the user anything.
I have tried exporting all VBA modules / forms, saving the template as a .dotx, closing and reopening then saving as a .dotm again and adding the code back but same problem persists.
Other templates for this client work fine. A deliberately added delete for a non-existent bookmark causes an error to be shown. The same delete call is ignored by the iffy template BUT the code stops running so it isn't doing Resume Next.
If I add a full error handler to the procedure concerned it does error and reports via my msgbox code.
In some respects this wouldn't matter, anywhere I am expecting errors to be a possibility I handle them but I have a certain amount of code that deals with images in headers and they are prone to errors. At this point I want the code to error where they happen so I can analyse how to get around the error, just telling the user isn't going to get the template working. What I have at the moment is the code "dying" and it is very hard to track where without putting in loads of debug statements and seeing where they stopped.
Has anyone seen something like this before? Could I have set something for this template specifically to tell it to not error on unhandled errors?
Other templates on the same machine error quite happily.
The template is very complex so I don't have the option to make it from scratch. Turfing out the VBA and putting it back didn't fix it. If I have to I can add handlers for all procedures but that shouldn't be necessary as errors won't happen once I have tightened up the code.
Any help really appreciated - for a few days I thought it was just VBA dying when working with images, now I really it is something more general than that.
Ok. I have found the source of the problem.
I had used a couple of standard procedures we have in various projects for conveying busy/not busy to the user - we call them InterfaceOn and InterfaceOff. They change the cursor, switch off screen updating, etc.
One line for the Off proc is "Application.EnableCancelKey = wdCancelDisabled".
I hadn't realised how severe that line is, it appears to stop the errors being reported and the code just dies. The help for it warns it is risky but doesn't explicitly state that it'll kill VBA on an unhandled error.
The InterfaceOn procedure has the line that reverses the EnableCancelKey restriction.
These procedures are used a lot so I am surprised this issue hasn't shown up before. Have removed the EnableCancelKey lines for now. No particular need to be that dramatic with this project.
This exception is being thrown by my ColdFusion application whenever I try to generate pdf reports using cfdocument.
Problem is, till 5 days ago everything was working perfectly and I was getting the reports. The suddenly, since yesterday morning, I have been getting the above error.
I have researched about this on the net extensively and have confirmed that:
1. Error is not occurring due to use of unknown fonts.
2. Missing CFM files.
Can somebody tell me if there is any other reason for this exception to occur suddenly.
I faced the same issue a few months back with one of my servers and has to re-install Coldfusion enterprise server. This is probably not the correct solution but can be used as a last resort.
Unknown if this is still an issue with CF9, but CF8 had problems with unscoped query variables inside the CFDocumentItem tag.
http://blog.dkferguson.com/index.cfm/2008/1/11/CFDocument--pdf-generation-broke-after-CF8-upgrade