I'm trying to debug and resolve some issues with a Win32 macro application written C++ however I'm having the strangest issue.
I have to launch a 16-bit program and then simulate entering data into and have been using ShellExecute for over two years now. I haven't touched this actual code at all, but now it doesn't work.
I'm doing ShellExecute(NULL, "open", exe_path.c_str(), NULL, "", SW_SHOWDEFAULT);. This has worked flawlessly for years but all of sudden, it stopped working. It gives me an ACCESS_DENIED error code. I've Googled and apparently this is a pretty common issue with launching 16-bit apps.
The workstation XP SP2 environment hasn't changed at all, and it was actually working until I rebuilt a little while ago (I've rebuilt it before many times).
The code is inside a window procedure function and when I take it out and launch the program in the WinMain function it works, but the code has to be in the window procedure...
I've tried numerous alternatives but they all give the same issue.
The biggest issue with this is it was working then all of a sudden decided it wasn't going to with no change to both code and environment! In fact, it was about half way through testing changes that it thought it'd stop working.
Please help as I cannot do anything without the program launching. It's the first step in the code that I'm debugging!
I've discovered the issue. I changed the lpDirectory parameter (of which I was supplying NULL or "") to the directory of the executable, using the PathRemoveFileSpec() function.
The application is launching again. Now I can continue fixing the rest of the program!
Related
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.
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.
I've run into an issue with a program I created using Livecode, and now I'm looking for some help from the experts. My Google-fu is strong, yet the answer eludes me...
So here's the deal. I made a very basic note-taking program for Windows only, using very noob skills. I've been using it daily for work for the past month at least. It functions exactly as it should, except for these few things that don't make sense:
When loading the program, it takes 25-30 seconds to load. Not convenient considering it's pretty basic; one button and 5-6 text input fields, with the same number of label fields. And one background. The button just clears the text input fields.
I started to notice a problem when I went to create a batch file to load all my work programs. When the program is loaded thru Command Prompt, if I close CMD it will close the program too. I tried the same using Powershell, and it still closes as soon as the Powershell window closes. Really really strange.
I managed to find another standalone program made with Livecode, downloaded it and tested the CMD command to see if the same thing happened. It didn't, that program loaded instantly and it is ENORMOUS. It also didn't close when I closed the CMD window. I even tried this: opened my program and the downloaded program using the same CMD session, and when I closed CMD, my program closed but the downloaded one did not.
Then, I downloaded the source code for the program that was working correctly. I created a standalone for it, and tried to open that. It acts the same way as my note program does.
I don't get it. It's got to be something in my Standalone Application Settings considering what happened in the last step I mentioned, and I've been over and over those settings for hours, but I just don't have the knowledge of LC to know what to look for. I've scoured the web looking for answers to this, but it seems to be just me having this issue (story of my life, lol).
I'll be happy to post any codes, scripts, or files needed, please let me know. I just don't know which things to post =P
Any suggestions are very much appreciated!! Thank you. =)
If you call the program from the prompt directly, e.g. using
C:\program files (x86)\your_standalone.exe
the app is treated as a command line app. I have also noticed that a LiveCode app can sometimes close if the invoking command line prompt is closed, while it may sometimes continue to run. Perhaps the handling of the relaunch message has to do with it, since this message basically handles commands from the command line.
If you want the command line process to finish independently from the invoked LiveCode application, you can use the start command:
start "" "C:\program files (x86)\your_standalone.exe"
don't have enough info to be able to tell what your issue is. But that much of a delay is not usual for LiveCode apps so something is definitely wrong. How long does your app take to load if you open the stackfile in the IDE?
Not sure what StackOverflow allows but if you could upload your scripts and if possible stackfile that will give us more to go on
This has nothing to do with Windows, Batchfiles, or CMD.
CMD can workaround your problem, if it's a GUI program. See Start command, and read the help as it explains the starting behaviour of CMD and CMD's Start.
Explorer has different rules. Anything else that starts programs call CreateProcessExW which has it's own rules.
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.
This morning I finally made my mind and decided to ask you for help. Problem is that in my Delphi application no hints are shown at all...
I have read about THintAction problem, I have read guides/tutorials/manuals, tried to invoke Hint windows ( firing event handlers ) manually, but nothing worked. They just doesnt show.
I have run out of ideas ...
I have tried to: setting parent showhints on components, forms, from event handlers, application activatehint() ...
Is there any other way to do this ( except API calls, of course )?
First, what version of Delphi do you use?
Second, I recommend you try creating a simple application from scratch, with just one form and say a tool-button (or any other control that can show hints), with ShowHints activated, and see if it shows. If on such a very simple app you'll get no hints, I would recommend reinstalling Delphi, maybe something in your installation is screwed up...
I bet you're on XP and your installation is rather old.
A friend of mine had this exact problem in his machine. No VCL hints were showing up in his machine. That includes the apps he built, the Delphi IDE he used (7 afaicr) and any other Delphi built app he had on his machine. So we had concluded by blaming his WinXP instance which has been on the run for the last 2 years with a lot of garbage in it (most likely it was some app he installed sometime that was hooking messages at some point causing this weird behaviour). It might be your case as well.
ps. Another interesting point - the hints were showing up if you set Application.HintPause to a low value like 100-200. You may want to try that as well.
Have you tried adding Application.ShowHint to your project file?
The project file would then look something like this
begin
Application.Initialize;
Application.ShowHint := True;
Application.CreateForm(TfrmMain, frmMain);
Application.Run;
end.
I've just had this problem on Delphi-5, "run-time application won't display hints on mouse-hover".
It works fine on my other applications.
I've traced it to the following:
Project|Options|Compiler|Debugging|Use Debug DCUs
This was checked, unchecking and re-compiling enables my hints.
A few tips:
Check if you or another component/unit has set a custom hint class. If so, find that component/unit and remove it.
Compile your application with Debug DCUs and put breakpoints at the appropriate places in Forms.pas. Then single-step through the code and see what happens.
Okay - As I Recently Upgraded to 2010 version ( 14.x ), I finally was sure that this Hint problem is Bug in the IDE.
Only solutions is:
- change the HintPause property
- try to reinstall IDE
I also encounter my PC( win10 ) can't show my ap's (made by Delphi 7) hint.
work again after I put following line in .dpr file :
100 is magic number, 500 or 1000 not working.
begin
Application.Initialize;
Application.ShowHint := True;
Application.HintPause:=100;
Application.Run;
end.