Breakpoints not triggered

I have a C# .NET project that is being developed in Visual Studio 2015.
This project is a web project delivering REST web services and is created using Web Api 2.

I can open this solution in Rider without any problem.
I can actually also Run or Debug this program in Rider. It will start up without any problem. And the webservices funtion without any problem.

However, when I try to set a breakpoint they don't get triggered and the breakpoint is marked with : Not found associated module for breakpoint Xyz.cs:999



Since I am already using 

  • Android Studio for the Android client
  • IntelliJ for the GWT based web client
  • AppCode for the iOS client

it would be nice to be able to use Rider instead of VS for the development of the services.

49 comments
Comment actions Permalink

Hi Frank,

I've just hit this issue as well, but I managed to overcome it by isolating the issue.. (At least for my case).

 

In my case the root cause is by having the rider folder and the solution folder on two different drives.

I am running on Linux, and in my case this means that the ~/.Rider2018.1 folder and the source code were on different drives.

When I move the source code to the same drive as Rider breakpoints started working again.

 

1
Comment actions Permalink

Thanks for the headsup Dans.

I reinstalled my Rider to the same drive as the solution but this sadly did not helped me :-(

1
Comment actions Permalink

Hi there!

Thank you for your feedback.

We are truly happy to hear that you enjoy using Rider.

Frank, could you please reproduce the issue and collect Rider logs after that (Help -> Compress log and show in Explorer)?

Thanks in advance!

Dans, thank you for the such a specific case. I've created an issue in our tracking system. Please, feel free to vote for it.

 

Sofia

 

2
Comment actions Permalink

And how do I submit these logs to you ?
That zip is 100MB in size.

0
Comment actions Permalink

Breakpoints are now working.

 

Run --> Attach to a local process... --> w3wp

0
Comment actions Permalink

Frank, thanks for your reply. 

Could you please confirm that you first ran an application, opened the web page (or called a service) and only then attached a debugger?

I'm asking because the module isn't loaded before you call the application (follow a link, for example, or call a service), and this is the reason why breakpoints are not resolved before you do this.

So, to use a debugger you just need to start debugging session and open a web page (or call a service ) of the application. After that, breakpoints will be resolved.

Perhaps, the message "Not found associated module for breakpoint" is not the best in the case above.  I created an issue, and we will try to improve usability.

 

0
Comment actions Permalink

What I did before was :

 

  1. Open the solution
  2. Set some breakpoints
  3. Click the 'bug' button in Rider (next to the play button)
  4. Chrome would open up automaticly with an URL pointing to my services
  5. The service would work as expected, but breakpoints would not work
  6. Stop the service
  7. Modify some code
  8. Start the service
  9. Refresh the Chrome Windows from step 4
  10. I would see the modifications in Chrome. But no breakpoints would get hit.

 

Now the only thing I changed is that in after step 2 I now do a Run --> Attach to a local process... --> w3wp

After this I just do the same steps as before, but now the breakpoints do get hit...

0
Comment actions Permalink

Very weird.

I would appreciate if you collect and send us DebuggerWorker logs (Help -> Show logs in Explorer / Finder). 

0
Comment actions Permalink

Have the same problem. 

But I have a bit tricky configuration (which works perfectly in Visual Studio though).

I have a separate project, which builds before main, then target DLL copies into Plugins directory for main project and main project loads all DLLs from Plugins directory into AppDomain.

In log I can see:

```

14:09:10.683 |T| SEND | Debugger worker MTA main thread:3 | signal `DebuggerWorkerToFrontend.DebuggerWorkerModel.activeSession.$.debuggerOutput` (5773224205282569435):: value = OutputMessage (
output = "Pdb file for assembly <assembly name> was not found or failed to read
"
type = Info
subject = Default
)

```

0
Comment actions Permalink

I have the same problem, also affecting Rider 2018.2.3. My prpject used to be on the same drive as the Rider binaries. When I move the project to a different drive, breakpoints do not work anymore with message 'not found associated module for breakpoint Main.cs 21,4' which is the location of the breakpoint. Just moving the solution back to the original physical drive solves the problem.

In my case the Rider binaries are on the same drive as the project but that is not the same drive as ~/.Rider2018.2. Moving the project to the same drive as where ~/.Rider2018.2 is, then it does not work.

I have not used Visual Studio at all in this project. It is al 'Linux only' built version. I am on Linux Mint (Ubuntu 18.04 based).

0
Comment actions Permalink

Having the same issue, however I moved the project to the same drive as .rider folder and the rider binaries themselves, so everything located on the same drive, the rider is the version 2018.3 EAP 3 (183.3647.257) version.

I'm using ubuntu 18.04

In my case the project is being run through :

/usr/bin/mono --debug --debugger-agent=transport=dt_socket,server=y,suspend=y,address=127.0.0.1:55555,setpgid=y /usr/lib/mono/4.5/xsp4.exe --address=127.0.0.1 --port=5000

 

I've uploaded the logs to your servers at https://uploads.services.jetbrains.com/

the file name is: 

logs-20181021-185657.zip

Can't debug, which is very very frustrating, what can I do to help you fix this problem?

 Thank you,

 

0
Comment actions Permalink

Update: After cleaning the solution and reopening it not through symlink, but directly I was able to debug it.

So my issue is exactly the same as the others, where the solution must be located on the same disk as the rider binaries in order for the debug to work, I have a strong suspicion that the mono process (/usr/bin/mono) also must be located on the same disk.

 

Thank you,

 

0
Comment actions Permalink

Hi

At the moment debugger does not work with symlinks. Here is a corresponding issue.

0
Comment actions Permalink

Hi 

I am having the same trouble but it is intermittent. I've a fairly simple solution with a domain project and a web project using IIS express. I do have my project on a different hard drive than rider is installed on (64 bit rider on win 10 box). I'm still not sure what the cause is but the regular things one might try do not seem to help ...

1. Deleting bin/debug folders

2. File --> Invalidate Caches 

3. Rider restart

4. Windows restart

5. Attaching to iisexpress after it has started

At a bit of a loss as to what I might next try. Any suggestions would be helpful. 

 

 

 

0
Comment actions Permalink

Hello!

The fix is available in Rider 2018.3 EAP.

Please, try it and feel free to let me know if the problem persists.

0
Comment actions Permalink

I've updated to that build and the problem has been fixed for me. Thank you Sofia (and Jetbrains). 

 

 

 

 

 

1
Comment actions Permalink

Had the same issue and fixed it. In my case problem appeared when I start project from mounted drive (via subst). Solved by starting project by full path (via Unity Hub) and cleaning csproj/sln files and obj, Temp, Library\ScriptAssemblies folders

Windows 10, Unity 2018.2.13f1, Rider 2018.3.1

0
Comment actions Permalink

I was getting this issue with skipping breakpoints in my Unity project with Untiy 2018.3.0f2 and Rider 2018.2. Rider and the project were installed on different hard drives.

Updated to Rider 2018.3 today, tried it on different hard drives, just like in the previous setup. The issue was not fixed, but I started getting grayed out breakpoints when I attach the debugger and warnings of type:

Tried re-installing Rider on the same hard drive where the project is. Still getting the same warnings and breakpoints not triggering. Deleting the csproj/sln files and obj, Temp, Library\ScriptAssemblies folders did not help. Installed Unity Hub. Not sure if I understand what is meant by "starting project by full path", but just opening the project from Unity Hub did not change anything. 

Would appreciate any help with this. 

1
Comment actions Permalink

I have the very same problem, occurs for the 2nd time. The 1st time I fixed it as Chill Water suggested. At that point I used Toolbox. Now I'm running without Toolbox and cannot fix the issue. For some of my classes the breakpoints are greyed out, mostly for the newly added. Any help? This really annoys and complicates the debug.

BTW, my project is on an external SSD and I CANNOT move it to my main drive. I use macOS.

0
Comment actions Permalink

Hello!

Denis, Vovo, did you tried reproducing on Rider 2018.3.4? Could you please try to delete bin and obj directories, then rebuild your project and check if the problem persists. If so, please clarify the exact Rider version (Help | About or JetBrains Rider | About). 

For 2018.3.4 you need to enable "Debugger" trace scenario in Help | Trace Scenarios (LOGS), then reproduce the problem, and collect logs (Help | Compress Logs and Show in ...). Do not forget disabling tracing after all.

Please, share collected logs via https://uploads.services.jetbrains.com or as an attachment to a new youtrack issue.

 

Thanks.

0
Comment actions Permalink

Hello Sofia, thanks a lot for the reply.

The Rider exact version is 2018.3.4. I have tried what you suggested, but the problem persists.

I've uploaded the logs to upload services. The exact filename is:

logs-20190404-104609.zip

Looking forward yo your reply.

Best regards, Denis

 

0
Comment actions Permalink

Hi again. I do not know whether this is an intended behaviour, but now the breakpoints are triggered. Here's what it looks like:

1. I put the breakpoint. The unity is in edit mode. The breakpoint is red.

2. I start play mode. The breakpoint is greyed out with an error.

3. When a class where the breakpoints are set is touched by the execution within Unity, the breakpoints become red and are triggered.

So, it works but in a weird manner. Or is this intended?

2
Comment actions Permalink

We have exactly the same issue. The only way we can trigger breakpoint with Unity, is to wait until Unity touch the class, toggle off and on the breakpoint. We are using a lot of asmdef in our project. I don't know if this could be the cause.

0
Comment actions Permalink

I am trying to decide if Rider will work for me or not.

I am trying Rider 2018.3.4, build #RD-183.6092.12 (Evaluation version) on Ubuntu 18.04.2 LTS.

I have the same issue.. even with a simple HelloWorld program, i got "Not fund associated module for breakpoint"..

Thus, I cannot  in this case even decide I Rider is the right IDE for my next C# Project or not!

0
Comment actions Permalink

Hello,
I've just found I have this problem, and thus this thread here. Using 2018.3.4 on Ubuntu 19.04 withing VirtualBox 6.0.6.
Just using a very basic .Net 4.7.2 HelloWorld

However, the problem appears to be fixed in 2019.1. EAP7, 6733.764, which I've just downloaded via the ToolBox.

Phew!

PS @Areftd. Hope this works for you. Compared to MonoDevelop 7,8,2 IMHO Rider is excellent.

 

1
Comment actions Permalink

@Jradxl, thank you for the tip.. it worked :)

though what is EAP7 for in this context?

0
Comment actions Permalink

I have a similar problem.  None of my breakpoints for the Unity project get hit.  I have to clear and reset them AFTER Unity is running, then they are hit.  When Unity first runs nothing is hit. I have the latest version of both. To make matters worse, it seems Rider does not support debugging Unity threads, whereas Visual Studio does. So far Rider is useless to me, so I plan to cancel membership shortly.

0
Comment actions Permalink

Hello!

Denis Daniltsev Design, Racinedavid1987, this is an expected breakpoints' behavior. The thing is that mono loads classes in a lazy way. That is why Rider cannot resolve breakpoints until the corresponding class is loaded by Unity runtime.

Areftd, the Early Access Program (EAP) provides free access to pre-release builds of our products: you can try our new features out early in return for your valuable feedback. This build is now unavailable because Rider2019.1 has been released.

James, could you please describe the repro steps?

1
Comment actions Permalink

I am still experiencing this problem, just updated Rider to v 2019.1.1 and my project is on the same drive as the Rider binaries. Any ideas?

I run my .net 4.6.1 application in debug mode, but on every breakpoint I get: "not found associated module for breakpoint"

-Magnús

3

Please sign in to leave a comment.