Unable to debug Webservice call on client side

This looks like a classic “debug host vs deployed host” problem rather than a bug in the service itself. When you run the page under Visual Studio’s development server the page’s origin (scheme/host/port) can be different from the IIS site where the ASMX lives; a script-generated proxy that ends up with an application-root path will be resolved against the page origin, not the deployed host, so the browser may be trying the wrong address and the request gets aborted (WinInet 12030). (learn.microsoft.com)

Practical ways to fix or debug this quickly:

• Run the page and the service under the same origin so the browser sees a single host/port (use Local IIS or configure your project to use the same URL/virtual directory you deploy to). That gives you the same runtime behavior when debugging as when deployed. (learn.microsoft.com)
• If you cannot use the same origin, add a small server-side proxy (an .ashx or MVC action) in the web app that forwards client AJAX calls to the ASMX; the browser talks only to the same origin proxy.
• If you control the service and want cross-origin calls, enable CORS on the service (or implement JSONP with care). Note that ASP.NET’s AJAX/ASMX stack intentionally restricts GET/JSONP and requires JSON content-type/security checks, so enabling cross-origin access often needs explicit server changes. (weblogs.asp.net)

Quick snippets to try while debugging (replace names with your paths):

// Global.asax - allow CORS for debugging only
void Application_BeginRequest(object sender, EventArgs e) {
  var ctx = HttpContext.Current;
  ctx.Response.AddHeader("Access-Control-Allow-Origin", "*");
  if (ctx.Request.HttpMethod == "OPTIONS") {
    ctx.Response.AddHeader("Access-Control-Allow-Methods", "POST,GET,OPTIONS");
    ctx.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type");
    ctx.Response.End();
  }
}

// build a same-origin URL at runtime
var svcUrl = location.protocol + '//' + location.host + '/virtualDir/YourService.asmx';

Debug checklist: watch the Network tab (or Fiddler) to confirm the exact request URL/Host/Port and response code, verify whether the server returns 401/403 vs a connection abort, and avoid using wildcard CORS in production. These steps will quickly tell whether the problem is origin/port mismatch or a server-side reject.