Categories

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.

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:

Listening on all interfaces of IPv4 (0.0.0.0) and IPv6 (“[::]”) with port 9000.

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:

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:

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 works in your Browser, and the IPv4 Listener is running, it is possible that your Firewall and/or Anti-virus software has decided to block:
A) The Java-based NetBeans program from making connections.
B) Apache (httpd) and PHP processes from making connections.
C) Port 9000 from being connected to.

You will have to either shut the Firewall and Anti-Virus applications off, or go through (and fix) their current lists of blocked and quarantined programs (NetBeans, Apache / httpd, PHP) and blocked ports (9000). Then create allow-rules and/or white-lists for NetBeans, Apache (httpd), PHP (php-fcgi), and port 9000.

I would start with McAfee and Kaspersky, by just turning them 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 bit, right-click on the php_xdebug.dll file, select Properties, and if it’s listed as “Blocked”, click to unblock it:

C:\WampDeveloper\Components\Php\ext\php_xdebug.dll

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:\ ?

I want to debug Magento with the parameters below.
But the “Waiting For Connection (netbeans-xdebug)” runs endlessly,
while the page displays in the browser with “localhost:99/magento/index.php?XDEBUG_SESSION_START=netbeans-xdebug”

I have set the localhost-Port on 99 because Windows 8 occupies the default-port 80. Could that be the problem?

If that does not help, then it could be your Firewall and/or Anti-virus software blocking Apache/PHP/Xdebug/Netbeans/Java from using the port 9000 connection. Check those firewall and anti-vir application(s) for any generated blocks.

Alright so, I have a weird situation happening here.
First thing to note: all of this worked fine prior to a Windows 10 factory reset.

My web servers all work properly; I have two virtual hosts, one on port 8080 and one on port 8008 (as well as TLS on 443 but that’s not important here). I’m having the same issue as above where it says that NetBeans is listening on the port, but Xdebug isn’t connecting to it… here’s the weird part: it only happens if I try to debug the port 8008 project. It works perfect on the port 8080 project.

I’ve been banging my head against the wall for hours and have no idea where to look. I’ve tried many different suggestions for Xdebug settings, but these were the same settings that all worked before reinstalling Windows 10 – same version of PHP/Apache/Netbeans, etc. Any ideas on where I should start looking?

If you are not using the loopback IP (127.0.0.1), but are using “localhost” or any other domain.name for remote_host, it might be resolving that name to some outside IP (or possibly the IPv6 “::1″ instead of IPv4 “127.0.0.1” interface for “loopback”).

Also make sure xdebug.remote_connect_back is turned off, or xdebug.remote_host will be ignored, and it will send connection to $_SERVER['REMOTE_ADDR'] – which might or might not be the proper local interface (depending on the VirtualHost’s domain.name you are accessing that is being resolved).

Netbeans is not listening to ipv4. All my settings for php.ini looks good but Netbeans is only listening to :::9000.
I have disabled the ipv6 for my Ubuntu 16.04 but no luck. How can I force Netbeans/Jave to lisiten to ipv4???

Many thanks! This was really helpful! I was getting desperate and worked through all of your hints. The issue had finally been my antivirus / firewall “Avira”. Had to uninstall it; then it worked.
Maybe that advice should be higher on the list? :-))
Could have saved me a lot of time I guess.

Check to make sure “localhost” is not being resolved to IPv6 loopback address ::1 (in Windows Hosts file), and is being resolved to 127.0.0.1. OR edit the xdebug php.ini settings to use 127.0.0.1 instead of “localhost”.

I’ve been spending hours on this problem, and I’ve searched dozens of sites.

I was about to write a long list of details about your setup and ask for your help, but then I read your post carefully again. My problem was that there are THREE places that the chosen port needs to match. Two of mine said 9001 and one said 9000. That was the problem and why Netbeans would only say “Waiting For Connection (netbeans-xdebug)”.

Thank you! Xdebug would not stop at breakpoints and didn’t even notice the ‘waiting to connect’ message. Finally noticed it and then found your post. xdebug.remote_enable was off, made the change and now breakpoints break. Much appreciated.