Netbeans “Waiting For Connection (netbeans-xdebug)” Issue

When NetBeans is unable to make a connection with XDebug, the NetBeans IDE will display message “Waiting For Connection (netbeans-xdebug)” at the bottom right corner…

Lets go through the list of things that can cause this issue.

* To save you all the reading, this issue is more than likely your firewall or anti-virus software blocking NetBeans from establishing a connection, or NetBeans attempting to connect with XDebug on something other than IP 127.0.0.1 (through a LAN or Public IP, or on the IPv6 interface) and port 9000.

Check NetBeans Project Configuration

After configuring XDebug and setting up NetBeans to use the same local web server, check the Project settings to make sure everything is correct:

Check XDebug’s Loading and Configuration

Make sure XDebug has actually been loaded by PHP, and it’s settings are correct.

The important settings are these:

xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_autostart=0
xdebug.remote_connect_back=0

This tells XDebug to enable connections to it, and to send the data back to 127.0.0.1:9000, which hopefully NetBeans is listening on.

Check Apache’s, PHP’s, and Website’s Error Logs

Check the specific website’s PHP error log file for any clues such as “unable to load module …” and “Call to undefined function …”.

Also check the general Apache and PHP error log files for the same messages or other errors.

* The PHP error log file will not exist if: you are using PHP-FCGI (in this case the errors are logged to each website’s individual PHP error log file), and/or no errors have been generated so far.

Check Browser

Does the URL http://www.example.com/ (substitute in your domain name) come up without any issues?

If not, then possibly:

• The Browser (or OS) is configured to use a Proxy which resolves the website’s Domain Name to somewhere else (i.g., not to 127.0.0.1).
• The Windows Hosts file might have the website’s Domain Name to IP resolve line missing, or using an IP other than 127.0.0.1.

Make sure NetBeans is closed, and restart Apache, don’t start NetBeans. Does the full query URL come up without any issues?

http://www.example.com/index.php?XDEBUG_SESSION_START=netbeans-xdebug

If not, then possibly:

• The website’s VirtualHost files or .htaccess file have redirect or rewrite rules that are breaking the request.

Check Rewrite and Redirect Rules

NetBeans will use a URL with a query similar to this:

http://www.example.com/index.php?XDEBUG_SESSION_START=netbeans-xdebug

Possible .htaccess and VirtualHost mod_rewrite rules that use, parse, and/or redirect requests based on the query string could break the request.

Clear Previous Sessions and Cache

Stop Apache, and delete all files in PHP’s and XDebug’s temporary folders:

C:\WampDeveloper\Temp\

C:\WampDeveloper\Temp\xdebug\

This will clear out any previous sessions so you can start with a fresh PHP session store and a fresh XDebug data store. Sometimes these temp files get corrupted, or don’t get cleared out properly, and things get hung up.

Check 127.0.0.1:9000 Bindings

Make sure that another process or program has not taken 127.0.0.1:9000.

Close NetBeans, stop Apache, wait a minute for all the Listeners to clear out, then open the command line (admin mode), and execute:

netstat -o -n -a | findstr 127.0.0.1:9000

If it finds a Local Address Listener (which is the 1st address, not the 2nd), you can cross-reference the PID (Process ID #) shown in Windows Task Manager, Processes Tab (click button: ‘Show processes from all users’ at bottom so it displays everything).

Whatever this turns out to be, it needs to be stopped and disabled, or re-configured to not take port 9000.

* The other option is to reconfigure both NetBeans and XDebug (php.ini) to use another port.

Check NetBeans Listeners and Connections

If the above is clear, verify that NetBeans is:

1. Listening on all interfaces of IPv4 (0.0.0.0) and IPv6 (“[::]“) with port 9000.
2. Taking a connection on 127.0.0.1:9000.

Start Apache, open NetBeans, load your project, make a debug point in the PHP code, and click to Debug it.

Once this is started, NetBeans should create the proper Listeners, and if everything is correct, start talking back and forth with Apache (if PHP is type:Regular) or PHP (if PHP is type: FCGI) between port 9000 and some random port of the Apache / httpd or PHP process…

netstat -o -n -a | findstr :9000

A good debugging connection between NetBeans and Xdebug looks like this:

  TCP    0.0.0.0:9000           0.0.0.0:0              LISTENING       5424
  TCP    127.0.0.1:9000         127.0.0.1:50821        ESTABLISHED     5424
  TCP    127.0.0.1:50821        127.0.0.1:9000         ESTABLISHED     6604
  TCP    [::]:9000              [::]:0                 LISTENING       5424

It shows that NetBeans (PID 5425) is Listening on all IPv4 addresses (0.0.0.0 includes 127.0.0.1), and that there is a connection Established to and from Apache / httpd (PID 6604).

* Names of processes are shown in Windows Task Manager, Processes Tab (click button: ‘Show processes from all users’ at bottom so it displays everything).

The important part here is that NetBeans is at least Listening on 0.0.0.0:9000. Otherwise, its settings are wrong, or something (usually firewall and anti-virus software) is preventing it from starting that Listener.

Is NetBeans Using a Non-Default Port (not 9000)?

If NetBeans is not using the correct port (9000), update NetBeans settings:

Tools, Options, PHP, Debugger Port

Or update XDebug’s php.ini settings to match that port.

Is NetBeans Only Listening On IPv6?

If there is no proper IPv4 (0.0.0.0:9000 or 127.0.0.1:9000) Listener, verify that:

NetBeans, and Java, have NOT been configured to prefer (use) IPv6 over IPv4:

For NetBeans -

Global Configuration File:

C:\Program Files\NetBeans 8.x.x\etc\netbeans.conf

Local Configuration File (might not exist):

%AppData%\Roaming\NetBeans\8.0.1\...

In option “netbeans_default_options” make sure it’s not set to prefer IPv6:

-J-Djava.net.preferIPv6Stack=true

If it is, change it to:

-J-Djava.net.preferIPv4Stack=true

For Java -

Open:

Control Panel - System - Advanced System Settings - System Properties - Advanced tab - Environment Variables

Check the environmental variables list for variable: _JAVA_OPTIONS

If it exists and contains:

-Djava.net.preferIPv6Stack=true

Change it to:

-Djava.net.preferIPv4Stack=true

Also open the Java Control Panel, and check if there are any Java Runtime Parameters (Java – View) or Proxy Settings (General – Network Settings) listed.

Control Panel - Java

* After these changes, reboot.

xdebug.remote_host

Make sure that NetBeans is working with IP 127.0.0.1, rather than the LAN IP or Public IP!

Otherwise, XDebug’s “xdebug.remote_host=127.0.0.1” will need to either be updated with the specific IP, or “xdebug.remote_connect_back=1” used to tell XDebug to connect back to ANY source IP…

http://xdebug.org/docs/all_settings#remote_connect_back

“If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER['REMOTE_ADDR'] variable to find out which IP address to use. Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.”

xdebug.remote_autostart

http://xdebug.org/docs/remote#browser_session

“When the URL variable XDEBUG_SESSION_START=name is appended to an URL Xdebug emits a cookie with the name “XDEBUG_SESSION” and as value the value of the XDEBUG_SESSION_START URL parameter.”

If there is an issue with cookies being set, “xdebug.remote_autostart=1” must be used…

“Normally you need to use a specific HTTP GET/POST variable to start remote debugging. When this setting is set to 1, Xdebug will always attempt to start a remote debugging session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.”

Check Firewall and Anti-Virus Software

If the NetBeans project settings are correct, the website work in your Browser, the IPv4 Listener is good, it’s possible that your Firewall and/or Anti-virus software has decided to block the Java based NetBeans program from making connections, and possibly also Apache and PHP, and/or port 9000.

You’ll have to either shut them down, or go through their current lists of blocked and quarantined programs (NetBeans, Apache / httpd, PHP) and blocked ports (9000).

And also create rules and whitelists for NetBeans, and for port 9000.

I would start with McAfee and Kaspersky, by just turning then off (some of these don’t fully turn off and have to be uninstalled). Then check Windows Firewall the same way.

Also, just to cover the last crumb, right-click on the php_xdebug.dll file, select Properties, and if its listed as “Blocked”, click to unblock it:

C:\WampDeveloper\Components\Php\ext\

Other

For best results while figuring out the cause of all this, to bypass all the external browsers, in the NetBeans Project’s Properties, Browser category, switch from ‘Default’ or ‘Chrome’ to “Embedded WebKit Browser”.

Some questions to ask yourself -

1. Have any other Apache or PHP extensions been loaded? Apache’s mod_security could easily block this (it’s never loaded by default in WampDeveloper Pro). Some extra PHP extensions might also conflict with XDebug.

2. Where there any changes made to PHP’s php.ini, aside from introducing the XDebug section? And also Apache’s configuration?

3. Has the website’s VirtualHost files been modified with php.ini overriding settings (“php_value” or “php_admin_value” setting “xdebug.remote_host=some.where.else”), other configurations, or access restriction?

4. Has the website’s .htaccess file been modified with php.ini overriding settings (as above), other configurations, or access restriction?

5. Where any extra .htaccess files placed into any of the parent folders (from the website), all the way up to C:\?