I wanna to play around the HP webOS, and doing something system level modification. As you may know that the webOS can inspect the source code, and digging inside the system with something like WebOS doctor with ssh. But I would like to inspect when I doing something, which lines of code is being execute, or.... at least which file is being execute, any ideas on that? Thank you.
You can use the Ares debugger - https://ares.palm.com/Ares/docstemp/debug.html
Or if you are developing in Enyo - you can use the Javascript debugger to set watches and breaks in your code. CTRL+SHIFT+J on a windows machine will bring that up.
Related
I do have Roku Express. I really dont know where to start with developing.
I have found where i can learn BrightScript used to build apps for ROKU.
(BrightScript Tutorial)
That is not an issue - but big question is where i can debug such as "channel".
Is there a way that i can use notepad++ and telnet for debugging purposes?
I have found notepad++ highlighter here: NOTEPAD++ BRIGHTSCRIPT HIGHLIGHTER
But i can not find eighter on google or here on stackoverflow how can i debug my application without playing with code and do trial/error, uninstalling, editing, zipping and sending it back to roku for testing.
Thanks for looking and hopefully some one know solution.
You don't need Eclipse for Roku debugging, there is no hidden magic in it.
All you have to do is side-load the ZIP, telnet <roku-IP> 8085 and then either:
interrupt the app with ctrl-C, or
have breakpoint placed in the app via the STOP statement
When execution breaks into debugger, you can type commands directly - check/modify variables, call functions and so on. When finished, resume program execution by typing c and hit Enter
You can do that with Eclipse! Check the link out: https://sdkdocs.roku.com/plugins/servlet/mobile#content/view/4265458.
You can use brihhtscript plug in for the Eclipse that will allow you to edit code, deploy it, debug... You can also use Atom with Roku dev package. You can debug using telent from terminal as well. Check your Roku local IP, open your terminal and type telnet 192.168.1.20(your ip address) 8085.
There is an excellent open source tool for Roku Debugging called VioletBug that I would highly recommend.
Roku Debugging is very easy with the help of the Visual Studio Code. It provides us a way to debug the code with the help of User Interface. Also, it automatically connects you with Roku with the help of telnet and we can use the debug console provided in VSC to print runtime variables and debug code.
More Details - Roku Debugging - VSC
Years ago, there were functions in Win32 whereby the app could check to see if a user was running the app via Terminal Services/Remote Desktop. I thnk it was something like:
GetSystemMetrics(1000H)
Is there a system call one can make to check to see if a Win32 or Win64 app is being run remotely via a program like GotoMyPC or LogMeIn?
No, there is not. Those are third party apps doing their own video/input capturing and network streaming. They are plain ordinary apps as far as Windows is concerned. Terminal Services is built into Windows, which is why there are APIs to query TS status.
The only way I can (currently) think of, other than using the aforementioned API call, is also seeing if any particular processes you can identify are running (e.g. GotoMyPC or LogMeIn... they will have some process running). Without doing too much research, they may be running without actually having someone using them. If, however, they launch something to do the streaming, you could check for that.
Just to make sure that this isn't an XY problem, what is it that you're trying to do - and perhaps there is another way?
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 ssh into a linux VM which is setup remotely. I use Vim to write my code. For debugging however, I use netbeans through X11 which can sometimes be painfully slow. I tried using gdb buts its an efficiency killer. I love to hover over my variable and get to now their value rather that doing p variable_name , plus I like see and navigate through the code. Is there something light simple gui based debugging tool I can use. I have tried to use clewn http://clewn.sourceforge.net/ , but that doesnt work because it has a missing netbeans_intg feature. Is there any other similar vim gui based debugging tool ?
You can try ddd
which is a gui for gdb, I think it's lighter than netbeans.
cgdb is an interface to gdb but it is not a graphical one. It does not offer the possibility of hovering over a variable, but it shows you a window with the source code.
Well, I was in sort of your situation sometime ago, and you can have a look at my question about using gdb with remote sources.
First of all, your problem with netbeans_intg feature is related to vim which has been compiled with no support for it. If you can rebuild vim yourself, you can then enable it. Otherwise, as you can see in the answer that I gave myself to my question, you can leverage clewn's remote-vim capabilities.
In a nutshell, you can have a "local" vim (i.e. on a desktop/laptop machine presumably), which must still be built with netbeans_intg support, but now it is a vim under your complete control (i.e. it's on "your" machine), while clewn will run on the linux host where gdb and your debuggee will run.
You can then keep the source files on your desktop/laptop and have the remote clewn sort of "drive" your local vim to the proper source files while debugging.
IOW: clewn will get information out of gdb to know exactly which file/line you're into and connect to remote vim and tell it: "hey, go grab this file and show it around this line", highlighting current line, breakpoints etc.
This is a great solution for when you have far-away deployed systems and you need to debug them with minimum impact on the host where they are running, and presumably no option to transfer there all of your source files.
I don't know if this fits in any way with what you're trying to do, but it did really change things for me.
Hth,
Andrea.
Check out GDB server. Theoretcially, you should be able to start gdb on your linux machine in server mode and connect via GUI of your choice. As long as that GUI supports remote gdb connections, which Netbeans does.
I am trying to get tracing set up for PowerShell(ISE) and I came across this link, but I am running debugView, and nothing seems to be happening. Anyone know what I am doing wrong?
Basically my goal is to get tracing for System.Net.WebRequest working in PowerShell. If there is another way to do it, I'd also be open to that.
The answer - which is mine funnily enough - in that link refers to the regular console (powershell.exe) version of powershell. I have to ask some dumb questions:
You created a powershell_ise.exe.config file, not powershell.exe.config, right?
If you're viewing dbgview over remote desktop, you enabled "capture global win32," right?
You have capturing enabled on dbgview, right?
-Oisin