Not a programming problem per se, but rather a programming environment problem that I have been unable to find a solution to.
The problem relates to Adobe's Extendscript Toolkit (both 3.5 and 4), but so far I haven't been able to solve the problem, so here I am...
The error I get has appeared more or less over night. I didn't experience this problem yesterday, nor this morning. But exactly WHAT has happened is beyond me. I have removed preferences, I have uninstalled, reinstalled, created a new user, restored old preferences from Time Machine and I'm now pretty much lost for options.
Basically, nothing works in ESTK anymore. Just opening ESTK and entering alert('Hello') won't work. Neither will $.writeln(). Everything running from within ESTK seems to give the same error;
Cannot execute script in target engine 'main'
With details:
Cannot execute script in target engine 'main'!
(#1116) Can't start debug session.
Below is a screenshot taken from the new user I created to test, same problem.
The "funny" thing is that all the scripts (InDesign CS5, still hanging on to it for reasons) still work perfectly in the applications' script panels. So there is nothing wrong with the scripts (heck, they haven't changed one bit, and still refuses to run in ESTK).
As mentioned, I've tried installing the ESTK CC (version 4) as well, but the very same problem occurs there. Which leads me to think the problem lies somewhere else, but I do not know where, and why.
So, if anyone can shed any light on this issue, at all, I would be very happy. Debugging is basically the only thing ESTK is good for in my book, but now that even that functionality is gone, I don't know how to efficiently debug the scripts which is kind of hampering the workflow.
For reference, I'm running InDesign CS5 (from the old Creative Suite) on a 2008 Mac Pro with 10.11.6 (El Capitan) installed. Well aware that it's pretty out of date, but that is beside the point here.
In the above mentioned forum, Adobe has published a stable workaround!You just have to correct a setting inside the estk application:
Open the file(Mac): “/Applications/Adobe ExtendScript Toolkit CC/ExtendScript Toolkit.app/Contents/SharedSupport/Required/cdic/11BTBackend.jsx”
Search for the value: 604800000 (line reads bt.timeout = 604800000)
Replace that value with 604800 and save
Quit ExtendScript Toolkit and relaunch.
I can confirm that it works.
From the adobe Forum :
"we have found a first workaround: just change your date to any date before 20-nov-2018"
https://forums.adobe.com/message/10761440#10761440
Seems like a date issue :(
I just published a quick update about this on the Adobe Tech Blog.
For the time being, if you dismiss the dialog, you can still run your script via ESTK and step through code as usual.
Alternatively, if you really want to avoid the dialogs, and you don’t mind setting your clock back, you can sidestep the issue by setting your system clock back to November 19, 2018 or before. On most systems, changing the system time can have unintended side effects, so this isn’t recommended unless you’re really certain about it.
Related
I have the following bug in a program:
An MDI MFC program closes silently on Windows 7 (terminates the process without prompting to save changes and without displaying any "crash" dialog) when the user performs this operation : Click a context menu item.
But this happens only on that PC, at least, for the moment. No other PC has encountered that problem. However the bug can always be reproduced following the same steps but only on that PC.
I want to know the reason but probably the customer won't allow me to install many programs to debug, so I need to be able to log when the program terminates, or print the stack in Release version but I'm quite lost.
I had faced a similar bug before and eventually I fixed it logging line by line and changing the problematic part, but I guess there are much better ways to find bug reasons than this.
I have tried on my development PC to create minidumps on Release mode but if there is no exception thrown on that PC, (I haven't confirmed that yet, though...) maybe it's pointless.
Also used an available class on codeproject (Stackwalker) but I don't manage to print all the function calls. Only on simple console programs, but not on MDI or even SDI.
Any ideas on how to find out the reason? Thanks in advance.
We've got a fairly mature cross-platform game engine which we've had running on OSX for several years now without a hitch; we recently upgraded the game from SDL 1.2.15 to 2.0, and at some point in the conversion, I goofed something up and now we have a bizarre problem where the app launches just fine from the terminal, but when you launch the app from a double-click in the Finder, it just bounces once in the dock and just goes away.
We're baffled because insofar as I can tell, there's only a one-liner being printed in Console.app: Exited with code: 255 (naturally running from the terminal doesn't help here because we can't reproduce the problem there; the app runs fine when launched in a terminal).
So the only thing we can figure is it's either something we're goofing up in our main.cpp, or something we've hosed in how I set up the dylibs/frameworks. It's also possible that it's something to do with the working directory not being set right, but to the best of my abilities, I believe we're doing it right (regardless of your current working directory; the app attempts to forcibly set said directory to be in the Resources folder - this was necessary to get the game to launch, but I don't know if we're doing it wrong). This feels like a somewhat awkward fit for stackoverflow, for which I apologize, since it's not a simple "paste this code and ask what's wrong" job. I have two ways for you to reproduce it; firstly we are an open-source project, and you can get our source code (complete with a mac project file and all dependencies included in the repo, set up and ready-to-go exactly as I've perhaps erroneously created them), at our github page. The one change you'll need to do is open a file at the root level, named master-config.cfg, and remove the // comments from it (so the engine knows you want to launch a simple demo game shipped with the engine).
Alternately, I have a stripped down (~15mb zipped) binary you can directly download and try to run, if that's sufficient to diagnose the problem.
As said before, we're open-source, so we welcome any pull-requests for fixes!
You need to write a minimal Cocoa wrapper so that OS X will not SIGKILL you for not launching properly. I will give you a pull request with that wrapper.
I have a VB6 application that I provide support for. This application works on both Windows XP and Windows 7. Some users were migrated from Windows XP to Windows 7 using the User State Migration tool. These users now receive a generic "Application has crashed" Windows error message when they open certain screens (forms) in the application. My assumption is that there is a missing dll/ocx reference, but I'm having trouble tracking it down.
I've tried many/varied troubleshooting techniques:
Full uninstall and reinstall of my application
Manually re-registering all dll's and ocx's that I know are used
Running Process Monitor on a broken computer and a working computer to compare what dll's and ocx's are accessed. The answer might be here but even after filtering out most of the background noise the amount of data is overwhelming. At a minimum I reviewed all of the calls right before it crashes and all of the calls that were not successful. All of the non-successful calls match between working and non-working.
Installed the Windows Debugger Tools and captured a crash dump. Analyzed the crash dump with DebugDiag. DebugDiag says the exception is in msvbvm60.dll. I tried building a PDB file for my exe and loading it in DebugDiag to get more detail about where the exception is occuring but DebugDiag doesn't want to accept the PDB (might be doing something wrong here, but it just seems to ignore it. This same PDB file works fine when I do remote debugging, however.)
I recompiled my VB6 program without any optimizations in PCode. I've read online that sometimes building in PCode, while bad for performance, will tell you the real exception.
Used the above created PDB file to remote debug the VB6 application. The debugger says that the application crashes after the new window has been created, on a line that sets MousePointer = vbHourGlass... To me it seems unlikely that this is the real cause of the error. There are at least 20 other locations in the program where this same line is called and all work fine.
(Forgot about this one)
Used Dependency Walker and profiled the application on both a working and non-working computer. All errors found by dependency walker were the same between the two computers. There were no additional dependencies found on a working computer, and all missing dependencies on the non-working computer were also missing on the working one.
None of these actions changed my error message or showed me what the error is (unless it really is the mouse cursor issue)... There are no entries in the Windows Event Log related to the app crash.
The non-working and working computers all have the same base Windows 7 image, the only difference is whatever is being changed by USMT, which further convinces me that this is some kind of quirky configuration change or a missing dll/ocx or perhaps an unregistered dll/ocx.
Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.
Update 1 - Response to questions
#MarkHall I have tried running it as admin, though not with UAC off. The application runs fine on a Windows 7 box as a non-admin with full UAC. Windows XP was 32-bit, Windows 7 is 64-bit, but again it works just fine on a like for like box where the user was not migrated from Windows XP.
#Beaner It's possible that it stores settings somewhere that have been corrupted, but the remote debugging leads me to think that it's more likely something else since it seems to die on a step related to the UI, which then makes me think it's probably a missing dll/ocx reference.
#Bob77 The application is installed into Program Files (x86). While many of the libraries do reside in the same folder, they are all registered.
Peter, often I've noticed that the debugger will indicate a line of code that is actually incorrect, depending on WHERE in the actual assembly language the fault occurs. You should look REAL close around your statement that sets the cursor to vbHourGlass. Your exception is PROBABLY happening BEFORE that line of code, but that line is what the debugger thinks is the actual faulted line of code.
Since you said it happens when a window OPENS, I'd look real close at any ocx's you may have referenced on the form, but perhaps NOT actually being used, or called. You might have one there that you don't intend to be there, that could be causing security issues, or something on Win7? Edit the .frm file by hand if you have to, and look at all the GUIDs the form references.
It is possible that one machine is using PER-USER registration, and the other is using PER-SYSTEM registration?? I don't know...
I would take a much closer look at the form that you are trying to open, and be VERY cautious of everything you are doing in the form load events, and so on. This sounds like it could be something as stupid as Windows Aero being enabled on one system, and not another, or some other sort of "Theme" setting that is throwing the VB Form Rendering routine into a hissyfit... Perhaps even something as stupid as a transparent color index in the icon you selected for that from?
If you are still developing this app, (or at least maintaining it), create an entirely NEW form, and re-create all the controls, etc, on the form (resist the temptation to copy/paste them from the old one...), and then see if THAT does the trick. Then, copy all the event code to the new form one event at a time, with at LEAST enough event code to make the form function, even if it's just a "dead form", that loads no data, or whatever the form is supposed to do. Check and debug after each change, and you WILL find it eventually. Of course, make sure you isolate one of the defunct systems to have a platform that you can duplicate the issue on, or then it's just guessing. I find that using something like Acronis w/ Universal Restore is a great option to then take the image file into a good HV, like VirtualBox, and then restore that image as a VM, so you can debug without interfering with your actual users. This sounds like a lot of work, but then again, so is re-writing an application that already exists, right? :)
Failing THAT... /* and */ are your friends!! (Well, we're dealing with VB, so ' would be your best friend! heh... But I'd start commenting out all the code on the form until that sucker opens. Then once it opens, start putting one line back at a time, and re-running it... That's called "VooDoo Debugging", but sometimes, you gotta do what you gotta do...
THANKS A LOT PETER! :) Now you got ME so involved in this, I feel like I'M the one debugging this sucker! Like if it was MY code I was trying to fix! :)
Let me know if any of this helps... I am actually quite interested in what you discover.
I believe this is similar to the thread: Canon SDK 2.11 on OSX
However the solution there did not work for me. I'm perplexed because I'm not sure how to figure out what has changed. I had some working software, did not work on it over the holiday and now when I open it up to work it fails. Not only my software but the demo app included with the SDK, which I have never changed and indeed used to work just fine.
I have tried with two different cameras (5DmII and 5DmIII) with the same result.
when I try and run the application, the camera is recognized but, as it attempts to open a session it receives a EXC_BAD_ACCESS signal. In each program it happens when a call is made to EdsOpenSession() with this message...
*** -[NSConcreteData release]: message sent to deallocated instance 0x8157af0
Interestingly, when I tried to use the EOS Utility that would crash also. So I updated and now that works great. I followed the suggestion in the above thread and copied the EDSDK.framework from the working bundle to my program and recompiled but I get the same results.
I'm trying to figure out how to contact Canon to get some information but they don't make it easy to get help so I'm appealing to the one group I know is responsive.
The only thing I can think is that sometime over the holiday I updated some critical library without knowing it.
Has anyone else run into and been able to solve this?
I'm running OS X 10.7.5, xcode 4.1, and EDSDK 2.11.3
Solved this. It did turn out to be the same solution as the mentioned link. However, what I was missing was that I needed to also copy the new EDSDK.framework into /Library/Frameworks not just have it in my source directory. This may be because I don't have everything setup correctly in XCode.
How can I find what's hanging all new installations on a Windows box?
While testing an installation script on Windows (XP Pro, if it matters) I've run into a situation wherein any and all attempts to install anything on the system hang waiting on who knows what. When the system is restarted, all queued up attempts at installation then go through their exit paths with pop-ups that report the installation is being aborted due to system shutdown having been requested. Of course, reboots do not cure the problem. The system otherwise runs fine.
So... How can I determine what part of the OS I've wedged? (Something in the registry, I suppose, but I'm a real greenhorn when it comes to Windows.) Most likely, something from a preceding install attempt went awry and is now blocking even though I saw no errors reported. Once I figure this out, I want to put in a check for this sort of thing, possibly at both ends of my install scripts, if that seems reasonable.
Thanks for your input.
UPDATE:
Unfortunately for me, rebuilding from scratch to get to the point the system's in now is about 9 hours. I'd like to unwedge it from where it is now rather than reload (again). Procmon seems great but I haven't got SP2 installed, only SP1! -frown- So, other ideas are welcome.
I assume you've tried logging the install to see where things go wrong?
Try rolling back to before things went wrong using "System Restore", if that doesn't solve it and the MSI log files show nothing useful then I'd take the plunge and reload before wasting any more time on it.
That said, if you're developing installers then taking an image of this PC in it's crappy state could be a worthwhile exercise. Some point in the future when you have more time to debug you can try and figure out what the problem is.
P.S. I'm assuming you're asking this question from the point of view of someone developing an installer and not as a tech-support question... otherwise this question should probably be closed as not-programming-related ;)
Try using Procmon to figure out where the installer is having problems, if you set a filter it will report all file and registry activity for that process.