Embedding your JavaScript and images inside a DLL was always a bad trade. You get tidy deployment and in exchange you lose the ability to look at a file and know what it is. WebResource.axd is where that bill comes due.
You spot it the same way every time. The network tab shows a 404 on WebResource.axd?d= followed by forty characters of base64 sludge, and nothing tells you which control or assembly asked for it. The d= is not random. It is the assembly and resource name, encrypted with your machineKey. The t= after it is a timestamp so the URL can be cached and busted.
That encryption is the whole problem. ASP.NET will happily tell you the request is bad and never tell you what it was for.
Telerik's Hristo published the fix back in 2007: a small aspx page you drop into the site that runs the same decrypt ASP.NET runs internally, with your machineKey, and prints the real assembly and resource name. The original link has almost certainly rotted by now, but the technique is what matters. Once you can read the d=, the cause is usually obvious. A version number that does not match what is sitting in bin, or a resource that got renamed between builds.
The cause nobody wants to hear is machineKey. Run more than one server, let ASP.NET auto generate the key, and every box encrypts that d= differently. A URL minted on server A is gibberish to server B, so you get intermittent 404s that vanish the moment you pull a single node out of the load balancer to test. Pin an explicit machineKey in web.config and the entire class of bug goes away. People file machineKey under forms auth and forget it signs this too.