First time debugging from PC to Mobile Phone work fine, when try again get error.
Any solution how fix this when try more debugging.
Add -debugport=54321 to Run->Parameters Parameters. By the way, the "inconsistent certificates" message is because the apk on the device was compiled with a different version of Delphi than the one you are using right now. You will have to uninstall it from the phone first. You can also use -cleaninstall in the Run->Parameters Parameters field.
There is no easy and fast solution.
You may need to:
Restart IDE
Kill adb.exe
Restart Windows
Restart device
Sometimes you will be able to debug again after doing only some of the above steps, however often you will need to do all of them.
Since every try takes plenty of time, I found out that complete Windows restart + device restart is the fastest thing to do.
With Delphi 10.3.3, it is enough to restart the device. After restarting the device problem goes away. It seems after the cancelation of code execution of the project debugged, the debugging service on Android continues to run. At this point, when new debugging started, IDE tries to run a new service with the same id of previous running service.
Related
I have an electron app with auto updater working perfectly. I'm able to release a new version and have it auto download and run the latest version. All works great. Now, I also have NSSM running to always make sure that my executable is always running.
However, this is also where the issue is. Because NSSM is always keeping my exe running, it's hard to update it when a new version is available. I'm assuming I'd have to stop NSSM first and then have the exe update itself and then somehow start NSSM remotely again.
How is everyone handling this whole process? Are you somehow handling this in your executable or have another process that handles this? Has anyone been able to do this successfully? I'm having hard time making this work. Just looking for some ideas here.
Am I even going about this the right way or is there any better way to handle this?
I found interesting problem with Win7/X64 machine.
For this time I haven't got problem with Delphi 6 and UAC.
The exes are working in their's place, so I can use Delphi debugger with them.
But today I got error on run the project: "Unable to create process. For this operation you need higher user level".
How can I prevent this side-effect?
What causes this?
I don't understand why the older projects are running fine, but this new isn't...
Thanks for every idea, link, information!
Additional info:
Normally I using the Delphi 6 IDE with normal starting (without SysAdmin rigths).
So it is never asking me with "really?" kind UAC questions.
And every of the older projects are usable with Delphi 6 - I can build, run, debug everything.
This problem happened with only this project, so I try to find the differences if possible to solve the problem.
I using normal directory ("c:\dev\anyproject"), others are using "c:\dev\otherproject1..2..n").
Does your application request elevation when started from Windows Explorer?
Does it have a manifest?
The name of the exe, like setup.exe, could also trigger elevation. See an outline of the Installer detection technology.
Non-elevated process can't debug elevated process.
If your application requires elevation at the start, then you would need to run the IDE elevated to be able to debug it.
Starting your IDE as an administrator should solve the problem (option in the context menu).
If not, you could always disable UAC while developing.
There is a number of limitations that needs administrator's rights.
For example: you cannot write data directly into program files directory.
I'm developing an application on two different machines (home and work) and while the home one seems to run just fine, the work one is, for lack of a better word, possessed. It has been exhibiting the following issues:
When loading the application, it will start at the simulator's main screen instead of starting the application at random intervals. You can start the application and have it work fine, then close the simulator, reload, and have the same codebase not load.
Going to applications doesn't show the application itself, in fact it never does.
Trying to load the applications cod file (File->load java program) never works. Tried the steps in this thread, with unreliable results.
Extremely small changes, such as modifying the value of a width variable by one, commenting out a function such as makeMenu or adding a button will cause code to no longer work, with no errors shown by the IDE.
Using clear.bat with sometimes work, sometimes not. Same with manually removing all files with the name of the project.
reinstalling the eclipse environment and the blackberry plugin did nothing more then burn off an hour.
having "load on startup" in the blackberry_app_descriptor.xml file is set.
Both systems are using Eclipse 3.5.1, BB plugin for eclipse 1.1 beta, Java 4.5 with the 8300 simulator. THe only difference that I am seeing is the operating system between the two systems. The work one being XP Sp3, home being vista. THe vista one isn't perfect, but I can test variable changes without flipping a coin to see if the app will even load or not.
I've tried the solutions that were similar on this forum, such as this one, but it looked to be that those solutions are dated as none of the options for the steps existed in my eclipse install.
So has anyone ran into such baffling behavior, and can it be fixed? Anything that I might have missed that could be tried?
I've been seeing this behavior with the new 1.1 plugin, the application doesn't load on startup and the FIle->load java program doesn't help. For me, the solution was I have to run a clean build every time, that is the eclipse clean and build instead of just build, not the clean.bat... Hope this helps!
Try clearing resources that have improper naming structure in your projects stuff with spaces or special character in the name of the file.
It took me two days to figure out.
One solution i got regarding your problem.
As I See Please run the application first time as Run as blackberry simulator
that is got start and here pick up run and then Run as Blackberry simulator
I want to debug App2.exe, which is started by App1.exe. If App2.exe were a dll I could specify a host application, but this doesn't seem to work with an .exe.
I now use 'attach to process', but this is useless if App2.exe crashes before I do that.
Is there a way to do this with having to attach to the process manually?
Set the "debug spawned processes" debugging option. It is off by default. When App1 starts the new process, the debugger will pause. If the debugger isn't already attached to the new process automatically, attach to it, and then resume running it.
No, but there might be a way to get it to attach properly. Find something that you know will happen in App2 soon before the crash point, and have it pop up a modal dialog box at that point. Then it won't continue until you dismiss it, giving you time to attach the debugger.
I guess you could launch app2.exe yourself and pass any necessary command line parameters to it.
If you're using windows, there is a built in support for it.
basically, you can tell the windows loader to launch some other process whenever a specific process is launched. for example, you can tell windows to always launch winword.exe whenever you click on notepad.exe
you can use this ability in order to automatically launch a debugger whenever you start your process (this is why this feature was originally introduced, however you are not restricted to launch only debuggers :))
You can read exactly how to do it here.
You can also download the debugging tools for windows package and use GFlags to do it for you.
If both apps are yours and you have the code than I propose the following:
Make a debug mode for both apps. Use external inc file for instance
Start two IDEs and load each app in its own IDE. Build in debug mode
If done right you can now debug the internal communication between apps
I have a project where a server spawns multiple exe worker processes that host each its own dll module. I have a debug mode in which I can specify which dll will be loaded and I can have both processes running and communicationt in between from IDEs. It is the best way I have found so far.
I'm having an interesting problem implementing a global keyboard hook.
I wrote a dll which is used to set the hook and then an application (Delphi) which loads the dll and processes the results of the hook. This was done this afternoon on my PC at work and after some testing I figured it was working 100%.
I've just tested the same app and dll here at home and I'm not getting any errors, but the application does not appear to be getting any data either.
Both machines are WinXP, although my work machine is SP2 and this one is SP3.
Has there been some change in the Win32 API which would cause this to malfunction, or could the problem be related to some A/V / Spyware / MS Update that has been released recently?
I'm hoping somebody here will know of an obvious reason that this may happen before I spend hours debugging.
Thanks!
Actually some A/Vs don't like homemade hooks. I've got the same problem with my mouse hooker on some machines, and it doesn't depend on service pack version.
Yeah, I could. I haven't installed Delphi on this machine, but I think I might have to. I'm going for the low hanging fruit here. If there's an obvious answer, there's no need to go through all the trouble of debugging and hoping to find what might be the problem.
My first suspicion is that there's been a change in the API somewhere.
As I mentioned, this app works absolutely perfectly on my work machine.
Do you have a debugger on your home computer? Do you receive any messages via the hook at all?
Can it be that some other application is hooking, and don't pass the message on down the hook-chain?
BTW: I love virtual machines for this kind of testing. Keep a clean XP install. Install SP2, and test your application. Roll back to clean install again, and install SP3. Try your application again. This way you will know if its SP3, since there is nothing else to mess things up. I like to keep a set of snapshots around with different configurations.
Which kind of hook are you using? I once used the WH_CBT-type and encountered problems when certain other applications where running. One case I could trace back to Trillian, which seems to do also some kind of hooking (and maybe screws up).
Apart from that I am currently working on an application that uses the WH_KEYBOARD-hook and this works on SP2 and SP3 equally well. The MSDN also doesn't mention any service-pack related changes.
What you can do to trace the bug on your home machine:
make sure to check all result values of all system api calls (and use GetLastError in case of error)
provide some kind of debug output in case of error (e.g. as message box or to a text file)
optional: log some status messages so you know whats going on internally
One alternative is to use a low level keyboardhook. (Just a different param to SetWindowsHookEx). The hook is processed in the message loop of the registering thread, and thus does not need to inject a dll everywhere. And for some odd reason VirusScanners/Firewalls interfere much less with it. They often silently block dllinjection or normal keyboardhooks. Also removes the need to share the hHook across processes if you want it to work in older windows versions.
And if you abuse a keyboardhook to implement global hotkeys(Have seen that a lot) use RegisterHotkey/http://msdn.microsoft.com/en-us/library/ms646309.aspx) instead.