`ls` command not working as expected in windbg - windbg

Question

I'm debugging a piece of code and I got it to break at an exception. I have the relevant source and symbol paths set up, but when I use ls, it doesn't show or list the current source file, even when it highlights the line in the open source file I'm interested in when I select the correct stack frame.
Why is that? What am I not understanding? What is meant by 'current source file'?

Answer 1

When you are on an address where source file is not available (like _dbgbreakpoint on ntdll) issuing ls will emit the message "No current source file":
0:000> ln #eip
(7c90120e) ntdll!DbgBreakPoint | (7c901212) ntdll!DbgUserBreakPoint
Exact matches:
ntdll!DbgBreakPoint = <no type information>
0:000> ls
No current source file
ls by itself requires a preloaded source file using lsf or you need to set the .srcpath.
This loaded source file remains loaded until you remove it or another source file is loaded automatically by an event (i.e. if you do .restart and break on _dbgbreak and do a ls, it will show the stale source file that was loaded with lsf earlier):
0:000> .restart
ntdll!DbgBreakPoint:
7c90120e cc int 3
0:000> ls
77: PAttributeHeader psecondheader = NULL ;
78: PAttributeHeader pthirdheader = NULL;
79: PFileInfoAttributeRecord pfinforecord = NULL;
80:
81: memset(&dump,0,sizeof(dump));
82: fopen_s( &fp,"\\\\.\\PHYSICALDRIVE0", "rb" );
Using lsa . (notice the .) instead of ls, it loads the source for the current address.
The current line is denoted by > in the paste below .
Notice ls fails due to no pre loaded source file whereas lsa . gives you the source line.
0:000> g wmain
00401000 55 push ebp
0:000> ls
No current source file
0:000> lsa .
67: }FileInfoAttributeRecord,*PFileInfoAttributeRecord;
68:
69:
70: int _tmain(int argc, _TCHAR* argv[])
> 71: {