Showing posts with label debugging. Show all posts
Showing posts with label debugging. Show all posts

Friday, September 04, 2015

Debugging HTML5 running in iOS from Windows with Chrome dev tools!


In order to debug HTML5 running in Safari on iOS, I used to connect the iOS device to my Mac, open Safari, go to Developer menu(needs to be activated from Safari Preferences) and open the page.
You can find detailed steps how to do this on internet.

I tried to remote debug HTML5 with other tools (Telerik has one), but the best way is with an utility called ios-webkit-debug-proxy which uses Chrome dev tools!

You can find it here https://github.com/google/ios-webkit-debug-proxy and its Windows port: https://github.com/artygus/ios-webkit-debug-proxy-win32

It allows you inspect the WebKit (either the Safari or UIWebViews) running on the iOS device from your Windows machine with Chrome dev tools.
This utility connects to the WebKit for inspection.

Steps (most of these are written in https://github.com/google/ios-webkit-debug-proxy):
  1. Go to https://github.com/artygus/ios-webkit-debug-proxy-win32
  2. You can either get the compiled version or build from the source. I chose to built it from source just for the kicks.
  3. Run the ios-webkit-debug-proxy.exe
  4. In Chrome, go to http://localhost:9222/ to see web-browser tabs open in Safari or the WebViews on the iOS device. Click on a tab.
  5. A new window should open with Dev tools. Note the silver icon, click on it and choose to 'Load unsafe scripts':



Some things to keep in mind:

- note that a web server is being used. when inspecting a tab, the link is
  https://chrome-devtools-frontend.appspot.com/static/27.0.1453.93/devtools.html?host=localhost:9222&page=1
  not sure if this might be a security issue for what you're debugging.

- in the inspector window, clicking on elements in the Elements tab doesn't do anything; you can use arrow keys to navigate up and down in the DOM tree




Friday, November 16, 2012

Remote debugging in Visual Studio, target on a different domain

My computer is a Windows 7 32bits and I had to debug a ASP.NET 32 bit worker process running on a Windows Server 2008 64 bit machine.

The server is in a VPN and in a domain.

What I did was, on the server, I first ran this tool:

Start\Programs\Microsoft Visual Studio 2010\Visual Studio 2010 Remote Debugger (x86)

Make sure your user has permissions to debug the apps, so you can go to Tools\Options and click on Permissions. Your user should have Debug permission.

The tool says “Msvmon started  a new server  named ‘JohnDoe@VMXXXXXX. Waiting for connections’.

Now, in Visual Studio 2010 on my machine, I went to “Debug\Attach to Process” and in Qualifier, I put JohnDoe@XX.XX.XX.XX where XX.XX.XX.XX is the IP of the server. Note that I didn’t use the ‘JohnDoe@VMXXXXXX’. It didn’t work for me.

Two things worth mentioning:

1. you need to have the same user and password on the local machine. I created a separate account on my machine for this.

2. you cannot debug 64 bit processes from a 32 bit machine. Luckily, my processes were running as 32 bit processes so I could debug them.

Thursday, March 01, 2007

ASSERT, ASSERT and ASSERT. Also, always ASSERT !

Putting assertions in your code was always VERY important.
I constantly find its importance in my coding.
It is very important to always assert your variables\conditions along with the testing it ( 'if' statement ).
Also, another common use is in an algorithm. it is important to assert different conditions which might define a state at a moment, a state which I know it should be false\true (when i mean a state i mean a condition composed of multiple variables, variables which might not be in the same scope but I expect some specific values).
i am having situations where while coding, i come accross some asserts which make me say "wtf, how did that happen ?" and then i discover that the algo has some issues which were not obvious due to complexity (or my fatigue).

Friday, May 05, 2006

before debugging ...

.. you need to make sure you have the right pdb
on microsoft website there is a debugging package(holding WinDbg and other debugging tools) which has a tool called SymChk which can be used to bring the right pdb files from microsoft website.
the tool reads the version of your dll and exe files and tries to find the corresponding pdb for that version.


C:\Program Files\Debugging Tools for Windows>symchk /r c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 /S srv*c:\dbg\symbols\*http://msdl.microsoft.com/download/symbols

/r tells symchk to look in the 'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322' path and in all subdirectories in it

/s Specifies the directories containing symbols
c:\dbg\symbols\ is the location where the symbols are downloaded

if you need a specific DLL file to get symbol for, you can use this (for ole32.dll for example)

symchk c:\WINDOWS\system32\ole32.dll /S srv*c:\dbg\symbols\*http://msdl.microsoft.com/download/symbols

Now, in WinDbg you can set in File menu the location of the symbols.

also, if you want to start using adplus tool (info:http://support.microsoft.com/default.aspx?scid=kb;en-us;286350) you must set the debugging symbols path in the environment variable
_NT_SYMBOL_PATH
in the value put the path of the symbols(c:\dbg\symbols\)

usually adplus is used in 2 modes:
unexpected haning(used with -hang)
unexpected crushing (used with -crash)
see the msdn link above

i am using it for crashing:
"C:\Program Files\Debugging Tools for Windows\ADPlus" -crash -pn MyApp.exe -o c:\dumps

MyApp.exe must not include a path just filename.

another tool useful is this one: gflags (http://support.microsoft.com/default.aspx?scid=kb;en-us;286470)
usually pageheap is used like this:
"C:\Program Files\Debugging Tools for Windows\gflags.exe" /p enable MyApp.exe /full

again, MyApp.exe must not include a path just filename.